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Abstract 


— A  new  approaeb  is  presented  for  the  problem  of  allocating  labor  resources  among  ship 
overhaul  projects  in  a  shipyard.  It  is  based  on  a  management-level  model  of  project  execution, 
which  describes  the  alternative  distributions  of  labor  use  over  the  life  of  a  project.  The  model 
consists  of  a  network  of  major  project  components  called  aggregate  activities.  It  includes 
mathematical  constraints  which  ensure  that  activities  operate  consistently  with  each  other.  The 
analysis  of  data  on  a  large  overhaul  provided  valuable  insight  for  construction  of  the  model. 

A  linear  program  (LP)  is  used  to  dynamically  allocate  labor  resource  capacities  among 
projects.  The  LP  formulation  allows  the  impact  of  alternative  allocations  and  capacities  to  be 
studied.  Plans  for  future  projects  can  be  evaluated  under  various  assumptions.  Problems  of 
realistic  size  are  readily  handled  by  existing  computer  packages. 

The  aggregate  model  of  project  execution  is  proposed  as  an  effective  tool  for  planning  of 
multi-project  resource  use.  Although  the  model  was  developed  in  the  context  of  shipyard  plan¬ 
ning,  it  is  believed  to  be  equally  applicable  to  other  repetitive  construction  industries,  for  exam¬ 
ple,  aircraft  or  radar  systems  manufacturing.  It  provides  a  link  between  resource  planning  and 
detailed  project  planning.  As  such,  it  can  improve  management’s  control  over  project  perfor¬ 
mance  and  labor  productivity,  — 
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1.  INTRODUCTION  TO  NAVAL  SHIPYARD  PLANNING  AND  SCHEDULING 


1.1.  Current  Practice 

Production  activity  in  a  naval  shipyard  consists  of  a  variety  of  large  ship  overhaul  projects 
executed  concurrently.  Each  of  these  projects  places  time-varying  workloads  on  20  or  more  dis¬ 
tinct  labor  trade  shops,  with  total  labor  input  to  each  project  in  the  tens  or  even  hundreds  of 
thousands  of  man-days.  Project  durations  range  from  3  months  to  3  years. 

Overhaul  projects  must  be  phased  in  time  to  ensure  the  availability  of  certain  key  facilities 
such  as  dry  docks.  Furthermore,  the  projects  should  be  phased  and  scheduled  so  as  not  to 
overload  any  of  the  trade  shops.  However,  the  phasing  should  not  be  so  much  that  shops  are 
underloaded,  in  which  case  workers  tend  to  slow  down.  In  the  event  that  a  shop  is  under¬ 
loaded,  productivity  is  diminished,  and  hence  overhaul  costs  are  increased.  The  trade-off  of 
assuring  schedule  adherence  versus  maintaining  high  productivity  is  a  complex  management 
problem. 

To  motivate  the  research  reported  in  this  paper,  a  brief  summary  of  the  current  practice 
of  planning  and  scheduling  in  naval  shipyards  is  presented  here.  (This  summary  is  an  expan¬ 
sion  of  the  one  provided  in  [7].)  In  current  practice,  a  two-stage  procedure  is  utilized  for 
overhaul  planning  and  scheduling. 

First,  an  aggregate  planning  effort  is  undertaken.  Starting,  ending,  and  several  intermedi¬ 
ate  key  event  (milestone)  dates  are  established  for  each  project.  These  milestones  mark  the 
realization  of  key  phases  of  the  overhaul,  such  as  docking,  undocking,  test  completions,  etc. 
The  goal  is  to  select  dates  for  each  overhaul  which  are  feasible  but  which  also  promote  efhcient 
use  of  yard  resources. 

Second,  a  detailed  activity  network  is  developed  for  each  overhaul.  Estimates  of  duration 
and  required  shop  man-days  are  developed  for  each  such  activity,  and  the  activities  are 
scheduled  consistently  with  the  pre-established  target  key  event  dates.  The  goal  of  this  effort  is 
to  schedule  and  control  the  execution  of  each  overhaul,  so  that  milestone  dates  established  in 
aggregate  planning  may  be  realized. 

Aggregate  planning  is  accomplished  using  an  iterative  tabular/graphical  technique  known 
as  "planning  on  the  curve."  In  this  method,  a  hie  of  standardized  loading  curves  are  maintained 
for  each  class  of  ship.  These  curves  portray  the  percentages  of  total  man-days  of  labor 
expended  in  each  month  of  an  overhaul,  given  proposed  durations  for  the  realization  of 
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overhaul  milestones.  See  Exhibit  1.1  for  an  example.  By  multiplying  the  total  man-day  esti¬ 
mate  for  an  overhaul  times  the  percentages,  an  estimated  month-by-month  time  history  of  total 
labor  workload  for  an  overhaul  is  derived. 

If  start  dates  and  durations  for  each  future  and  ongoing  overhaul  are  specified,  the 
overhaul  time  histories  may  be  summed  in  tabular  form  to  develop  an  estimated  total  man-day 
workload  history  for  the  shipyard.  The  resulting  curve  is  compared  to  a  time  history  of  yard 
"capacity",  i.e.,  a  time  history  of  the  total  productive  work  force,  as  measured  in  man-days  per 
month.  See  Exhibit  1.2  for  an  example. 

As  shown  in  the  exhibit,  for  particular  trial  overhaul  durations  and  start  dates,  the  vari¬ 
ance  between  the  workforce  and  workload  curves  may  be  both  positive  and  negative.  A  planner 
would  experiment  by  trial  and  error  with  different  overhaul  start  times  and  durations  in  an 
attempt  to  match  the  workload  curve  and  the  workforce  curve  reasonably  closely. 

Recall  that  the  different  labor  shops  have  been  aggregated,  so  that  an  aggregate  plan  in 
which  total  workload  coincides  with  total  workforce  may  still  be  characterized  by  overloading 
and  underloading  of  particular  shops.  Costs  of  underloading  are  thought  to  be  more  severe 
than  costs  of  overloading,  so  that  in  practice  an  aggregate  plan  is  sought  in  which  the  workload 
curve  lies  about  10%  above  the  workforce  curve. 

Each  time  an  aggregate  plan  is  completed,  key  event  dates  are  fixed  for  all  upcoming 
overhauls  which  will  begin  within  some  scheduling  lead  time;  dates  for  other  overhauls  are 
treated  as  tentative,  and  may  be  changed  in  future  plans. 

Once  milestone  dates  for  an  overhaul  have  been  set,  the  scheduling  of  detailed,  com¬ 
ponent  activities  of  the  overhaul  is  undertaken.  Typically,  thousands  of  activities  known  as 
kQf-ops&Te  defined,  an  undertaking  requiring  a  year  or  more.  Durations  and  man-hour  require¬ 
ments  from  each  trade  shop  are  estimated  for  each  key-op,  and  a  critical  path  network  of  the 
key-ops  is  developed.  In  the  scheduling  effort,  network  slack  between  milestone  dates  is  uni¬ 
formly  allocated,  which  tends  to  reduce  shop  loading  peaks. 

Milestone  dates  and  key-op  schedules  are  distributed  to  line  (shop)  production  manage¬ 
ment,  which  is  responsible  for  the  day-to-day  allocation  of  working  crews  and  job  supervision. 
In  practice,  adherence  to  key-op  schedules  is  rare,  but  observance  of  milestone  dates  is  accom¬ 
plished  where  feasible. 
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1.2.  A  System  for  Improved  Planning  and  Scheduling 

In  our  opinion,  there  are  several  problems  with  this  method  of  planning  and  scheduling 
which  we  feel  are  worthy  of  research  and  development.  As  previously  mentioned,  aggregate 
planning  is  performed  by  aggregating  capacities  of  non-substitutable  resources.  If  a  method  for 
planning  were  developed  in  which  trade  shops  were  treated  as  distinct  resources,  the  underload¬ 
ing  and  overloading  of  shops  inherent  in  the  current  method  could  be  reduced,  providing  the 
potential  for  gains  in  both  productivity  and  schedule  adherence. 

Second,  linkage  between  aggregate  planning  and  project  scheduling  now  exists  only  in  the 
form  of  milestone  dates.  The  aggregate  plan  is  prepared  with  certain  resource  load  histories  in 
mind,  but  there  is  no  guarantee  that  loading  histories  of  detailed  overhaul  schedules  are  con¬ 
sistent  with  aggregate  plans.  The  appropriate  allocation  of  shop  capacities  to  an  overhaul  is  only 
implicitly  suggested  by  milestone  dates. 

Finally,  overhaul  scheduling  and  control  is  attempted  at  too  fine  a  level  of  detail,  since 
key-op  schedules  are  largely  ignored  in  actual  operations.  Less  detailed  key  operations  need  to 
be  defined,  in  which  the  level  of  detail  is  more  consistent  with  the  scheduling  constraints  per¬ 
ceived  by  line  management.  Networks  with  hundreds  of  key-ops  rather  than  thousands  should 
be  used  for  scheduling  and  control. 

We  envision  an  ideal  shipyard  planning  and  scheduling  system  as  shown  in  Exhibit  1.3.  A 
more  detailed,  computer-aided  aggregate  planning  effort  would  be  undertaken  which  explicitly 
considers  the  various  trade  shop  capacities.  Key  event  dates  and  allocations  of  shop  capacities 
would  be  established  for  each  overhaul  based  on  a  plan  which  is  feasible  and  maximizes  yard 
productivity.  In  parallel  with  aggregate  planning,  detailed  overhaul  planning  would  take  place, 
in  which  standardized  key-op  networks  appropriate  for  scheduling  and  control  are  calibrated  as 
to  resource  requirements  and  duration.  Overhaul  scheduling  and  control  would  be  conducted 
using  such  data.  Moreover,  schedules  would  be  derived  which  are  consistent  with  the  key 
event  and  shop  capacity  constraints  specified  in  aggregate  plans.  The  execution  of  the  overhaul 
would  be  controlled  by  monitoring  the  completion  times  of  scheduling  activities,  which  we  term 
principal  events. 

This  paper  concerns  the  development  of  an  aggregate  planning  methodology  for  such  a 
system.  Central  to  the  methodology  is  the  development  of  an  aggregate  overhaul  model,  with 
(aggregate)  activitie:  .  fined  at  the  key  event  level  of  detail.  This  model  builds  on  the  dynamic 
production  modeling  work  ul  Shephard  et  al.  [10]  and  Leachman  [6],  but  work  flow  between 
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IDEAL  SHIPYARD  PLANNING  AND  SCHEDULING  SYSTEM 


activities  (intermediate  product  transfer)  is  treated  in  a  new  manner. 

The  reader  is  also  referred  to  [7]  and  [11].  In  [7],  the  aggregation  of  a  1150  key-op  net¬ 
work  into  a  430  key-op  network  (at  the  principal  event  level  of  detail)  is  discussed,  as  well  as 
multi-shop  resource  leveling  techniques  for  the  derived  network.  In  [11],  scheduling  of  the 
same  network  subject  to  shop  capacity  allocations  is  investigated.  At  this  point  we  terminate 
our  general  discussion  of  the  planning  and  scheduling  process  in  naval  shipyards,  and  proceed 
to  the  technical  development  of  new  models  appropriate  for  aggregate  planning. 


2.  NETWORK  REPRESENTATION  OF  SHIP  OVERHAULS 


2.1.  Introduction  to  Activity  Networks 

A  construction  project  can  be  represented  graphically  as  a  collection  of  activities  which  are 
the  nodes  of  a  network.  The  arcs  of  the  network  indicate  dependence  relationships  between  pairs 
of  activities,  as  described  below. 

Each  activity  operates  by  using  resources  (labor  from  different  shops)  over  a  period  of 
time.  These  are  denoted  by  Ri, .  .  .  .Rjt-  operation  also  depends  on  the  availability  of 
intermediate  products  from  other  activities  (its  predecessors).  The  activity  itself  produces  inter¬ 
mediate  products  that  other  activities  (its  successors)  use.  The  network  arcs  refer  to  these 
dependences.  The  generalization  of  network  arcs  to  represent  product  transfers  rather  than 
simple  precedences  is  due  to  Shephard  et  al  [10]. 

Transfers  of  intermediate  products  between  activities  may  consist  of  flows  of  work  in  pro¬ 
cess,  or  may  effectively  be  "go-ahead"  signals.  In  detailed  networks  an  activity  produces  a  dis¬ 
tinct  product  for  each  of  its  successors;  in  more  aggregate  networks  there  may  be  "sharing"  or 
"pooling"  of  intermediate  products,  as  will  be  discussed  in  Chapter  3. 

In  this  chapter  we  will  encounter  two  types  of  activity  networks.  The  key-op  network  is  a 
detailed  representation  of  a  ship  overhaul.  The  aggregate  activity  network  is  a  management-level 
representation  with  less  detail.  They  differ  with  respect  to  assumptions  about  activity  operation 
and  intermediate  product  transfer  between  activities. 

We  have  chosen  the  activity-on-node  representation  of  an  activity  network  since  it 
emphasizes  the  flow  of  intermediate  products  through  the  network.  The  equivalent,  activity- 
on-arc  networking  scheme  is  also  frequently  used.  (See,  for  example,  Moder  and  Phillips  [8].) 

2.2.  Key-op  Networks 

For  each  overhaul,  planning  information  exists  in  considerable  detail.  Much  of  it  is  based 
on  previous,  similar  overhauls.  Hundreds  or  even  thousands  of  detailed  activities,  called  key- 
ops  (key  operations),  are  defined  for  overhaul  scheduling  and  cost  accounting  purposes.  For 
each  key-op,  estimates  are  prepared  of  work  duration  and  labor  use  by  trade  shop.  A  key-op 
usually  requires  labor  from  several  shops  with  one,  the  lead  shop,  being  dominant. 

The  depende.nce  relationships  between  key-ops  are  described  in  the  key-op  network.  Tradi¬ 
tional  scheduling  assumptions  require  the  dependences  to  be  strict  precedences:  a  key-op  may 
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start  only  after  its  predecessors  have  finished.  For  this  reason,  key-ops  are  defined  at  a  level  of 
detail  at  which  transfer  of  intermediate  products  is  event-based,  i.e.,  when  the  key-ops  finish. 
A  distinct  product  is  then  transferred  to  each  successor  key-op. 

The  decomposition  of  an  overhaul  into  key-ops  is  guided  by  four  main  criteria: 

-  precedence  requirements  (as  just  described) 

-  labor  shop  emphasis  ("lead  shop") 

-  work  location 

-  technical  system. 

Key-ops  are  defined  at  a  level  of  detail  such  that  all  of  these  work  breakdown  criteria  are 
applied.  Leachman  and  Boysen  present  examples  of  key-ops  in  Reference  [7]. 

2.3.  Key  Events 

The  completion  of  each  key-op  is  an  event.  To  control  the  execution  of  an  overhaul,  the 
shipyard  identifies  certain  key  events,  which  represent  the  completion  of  logical  phases  of  the 
overhaul  or  the  realization  of  certain  work  accumulations.  We  distinguish  two  types  of  key 
events:  restraining  events  and  monitoring  events,  as  discussed  below. 

Restraining  Events 

Referring  to  Exhibit  2.1(a),  suppose  a  group  A  of  key-ops  must  finish  before  key-ops  in 
another  group  B  can  start.  We  could  represent  this  in  the  key-op  network  by  connecting  each 
of  the  key-ops  in  group  A  to  all  of  those  in  B.  A  better  and  clearer  way  is  to  define  a  key  event 
node,  represented  by  a  square,  which  succeeds  key-ops  in  A  and  precedes  key-ops  in  B,  as  in 
Exhibit  2.1  (b).  The  key  event  node  restrains  group  B  key-ops  until  group  A  has  finished. 

This  type  of  restraint  also  arises  when  certain  events  are  fixed  in  time:  group  A  key-ops 
must  operate  before  the  event,  and  group  B  key-ops  afterwards.  In  either  of  the  above  cases, 
the  restraining  event  is  a  control  point  for  transfer  of  intermediate  product  between  the  groups. 
Of  course,  event  nodes  in  the  network  use  no  resources  and  have  no  duration.  Several  impor¬ 
tant  restraining  events  occur  during  the  execution  of  an  overhaul,  for  example: 

-  docking  and  undocking 

-  completion  of  insulation  removal  before  machinery  space  components  can  be  removed 

-  completion  of  all  component  testing  before  testing  of  a  whole  technical  system  may  begin. 


Monitoring  Events 

Referring  to  Exhibit  2.2,  this  type  of  event  is  defined  when  the  completion  of  a  group  A 
of  key-ops  is  to  be  monitored.  We  represent  it  by  connecting  the  key-ops  in  group  A  to  an 
event  node.  Note  that  the  monitoring  event  does  not  restrain  the  start  of  the  successors  of 
key-ops  in  group  A. 

As  an  example,  consider  the  event  "Completion  of  all  Shop  Repairs  to  Engine  Room 
Components."  After  each  component  is  repaired  it  can  be  reinstalled  immediately.  But  to  mon¬ 
itor  the  completion  of  all  repairs,  or  equivalently,  the  tranter  of  all  repaired  components  to  the 
ship,  this  event  is  defined.  As  in  the  case  of  restraining  events,  monitoring  events  are  control 
points  for  product  transfer  with  no  resource  use  or  duration. 

Key  Event  Networks 

The  key  events  can  be  linked  together  in  the  form  of  a  network.  This  key  event  network  is 
not  an  activity  network;  rather,  it  displays  sequences  of  key  events  and  possibly  their  relative 
timing.  It  can  be  thought  of  as  a  skeletal  structure  for  the  key-op  network.  The  potential 
operating  periods  for  key-ops  can  be  constrained  by  specification  of  dates  for  key  events. 

The  key  event  network  provides  a  way  of  summarizing  the  execution  of  an  overhaul.  In 
Section  2.5  we  propose  a  different  kind  of  summary  network  which  focuses  on  major  overhaul 
acr/v/r/es  rather  than  events.  In  Section  3.3.1  the  connection  between  the  two  is  discussed. 

2.4.  Analysis  of  Key-op  Networks 

In  this  section  techniques  for  scheduling  of  key-ops  are  briefly  reviewed.  In  later  sections 
we  will  refer  to  the  notation  used  here.  We  denote  the  key-ops  within  an  o\'erhaul  by 
KOi . KOl. 

2.4.1.  Critical  Path  Method 

Each  key-op  KOi  is  assumed  to  have  a  duration  D/.  Let  5— {5|.  ...  ,5/.)  be  a  schedule  of 
key-op  suirt  times.  This  schedule,  together  with  the  key-op  durations,  describes  the  execution 
of  the  overhaul.  Given  a  start  time  5,  for  key-op  KOi,  its  finish  time  F,  is  simply 
We  assume  that  KOi  operates  in  the  half-open  interval  (5/,F/],  and  that  5/  and  A  are 
expressed  in  integral  time  units. 


The  Critical  Path  Method  (CPM)  is  a  well-known  technique  for  determining  the  set  of 
feasible  start  schedules.  (See  Moder  and  Phillips  [8],  Harris  [3],  Elmaghraby  [2].)  Given 
overhaul  start  and  finish  times,  and  possibly  key  event  dates,  we  can  bound  the  start  time  of 
each  key-op  in  the  following  way.  Let  KOi  be  a  key-op  with  a  successor  KO^  Then  KOi  must 
finish  before  KO„  can  start,  i.e.. 


^1  ^  S';  +  D/  <  S„  .  (2.1) 

Given  all  start  time  constraints  of  type  (2.1),  we  can  compute  the  earliest  and  latest  possi¬ 
ble  start  times  ESi  and  LSi  for  each  key-op  KOh  and  the  corresponding  finish  times  £F/  and 
LFi.  Every  feasible  start  schedule  S— (5/. ...  .St)  thus  satisfies 

ESi  ^  S;  ^  LS;  Z<  . 

The  earfy  schedule  is  denoted  by  ESMESi.  . . . ,  ESc)  and  the  late  schedule  by 
LS-{ZS, . LSl). 

The  slack  (or  float)  of  key-op  KOi  is  defined  as  ai=LSr-ESi.  It  is  the  amount  of  time 
that  the  start  of  KOi  can  be  delayed  beyond  £5;  if  its  successors  operate  late  and  its  predeces¬ 
sors  early.  The  key-ops  with  zero  slack  form  the  critical  paths  o(  the  network. 


2.4.2.  Resource  Use  Analysis 

It  is  assumed  that  each  key-op  KOi  uses  resources  at  a  constant  rate.  Let  bu  be  the 
amount  of  resource  (labor  shop)  Rh  that  KOi  uses.  The  operating  intensity  zi  is  defined  as  the 
proportion  of  total  resource  requirement  of  KOi  that  is  used  per  unit  of  time,  so  that 
z,sl/D,. 

Given  these  assumptions  on  key-op  resource  use,  a  start  schedule  S  completely  deter¬ 
mines  resource  use  during  the  execution  of  the  overhaul.  Let  t)  be  the  amount  of  resource 
Ric  used  by  ATO;  at  time  t.  Then 


mm  if  S’;  <  /  <  F; 

(0  Otherwise 


(2.2) 


Exhibit  2.3  graphs  this  resource  load  profile. 

Various  techniques  for  resource-constrained  project  scheduling  exist;  see,  for  example, 
Herroelen  [4],  Cooper  [1],  Patterson  [9].  Most  methods  employ  heuristic  rules  of  shifting 
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activities  (key-ops)  forward  or  backward  in  time,  with  the  objective  of  keeping  total  resource 
use  within  the  given  constraints.  This  corresponds  to  shifting  resource  load  "boxes"  in  time,  as 
Exhibit  2.3  illustrates.  Leachman  [S]  proposes  a  more  flexible  scheme  in  which  key-op  inten¬ 
sity  zi,  while  constant  over  time,  is  a  decision  variable.  This  is  equivalent  to  allowing  different 
key-op  durations  z/"',  and  stretching  or  compressing  the  resource  load  boxes  accordingly,  as  in 
Exhibit  2.4. 

2.5.  Aggregate  Activity  Networks 

We  are  interested  in  representing  the  execution  of  an  overhaul  at  a  level  of  detail  that 
facilitates  allocation  of  shipyard  resources  among  overhauls.  The  key-op  network  is  not 
appropriate  for  this  purpose  for  two  reasons: 

(1)  Data  Generation:  A  comprehensive  decision  model  that  attempts  to  set  key-op  schedules 
for  each  overhaul  while  determining  resource  allocations  to  overhauls  would  require  huge 
amounts  of  data.  These  data  are  not  always  available  when  they  would  be  needed. 

(2)  Computational  Problems:  Even  if  all  data  were  available,  the  event-based  restrictions  on 
resource  use  implied  by  the  key-op  network*  make  techniques  of  resource  allocation  computa¬ 
tionally  complex.  Performing  the  scheduling  simultaneously  for  all  overhauls  becomes  imprac¬ 
tical. 

For  these  reasons  a  less-detailed  model  of  overhaul  execution  was  developed.  We  intro¬ 
duce  the  concept  of  an  aggregate  activity  network.  Each  aggregate  activity  is  a  collection  of  many 
key-ops.  The  network  arcs  indicate  transfer  of  intermediate  product,  as  before.  Product 
transfer  is  no  longer  event-based,  however,  as  we  see  below. 

We  would  like  to  define  the  activities  at  the  highest  degree  of  aggregation  that  still  permits 
a  reasonable  representation  of  resource  use.  Since  the  level  of  detail  is  reduced,  we  cannot 
decompose  the  overhaul  tasks  according  to  all  of  the  criteria  of  Section  2.2,  at  least  not  to  the 
same  extent.  Recall  that  these  criteria  were  as  follows: 

-  precedence  requirements 

-  labor  shop  emphasis 

-  work  location 

-  technical  system. 

*a  key-op  can  start  to  use  resources  only  after  its  predecessors  have  stopped  using  resources 
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In  Section  3.3  we  show  that  it  is  appropriate,  for  example,  to  combine  different  com¬ 
ponent  removals  into  one  aggregate  activity  and  the  corresponding  shop  repairs  into  another. 
Since  some  repairs  can  start  before  all  of  the  removals  have  finished,  the  product  transfer  from 
the  removal  activity  is  more  flow-like  than  event-based.  Therefore  the  dependence  relation¬ 
ships  between  aggregate  activities  cannot  obey  the  "precedence  requirement"  criterion. 

The  "labor  shop  emphasis"  criterion  remains  important  since  resource  use  must  be 
modeled  accurately.  However,  work  location  and  technical  system  information  at  the  key-op 
level  may  be  aggregated.  For  example,  we  could  make  the  following  aggregations  of  key-ops: 

-  removal  of  condensate  system  and  feed  system  components  (two  different  systems,  but 
related  by  resource  use) 

-  painting  of  deck  and  hull  (two  locations  with  similar  resource  use). 

Since  an  aggregate  activity  is  a  collection  of  many  key-ops,  it  will  operate  at  varying  rates 
over  time.  Following  Shephard  [10],  we  represent  the  operation  of  an  activity  as  a  time  history 
of  operating  intensities.  Intensities  are  measured  in  some  physical  units;  in  our  case  they  are 
units  of  resource  use.  We  shall  refer  to  the  intensity  time  history  of  an  aggregate  activity  as  its 
operating  mode. 

A  particular  operating  mode  determines  the  time  histories  of  resource  use  by  the  aggre¬ 
gate  activity,  and  also  time  histories  of  intermediate  product  input  and  output.  Being  able  to 
describe,  and  select  from  among,  alternative  operating  modes  is  the  basis  for  our  approach  to 
resource  allocation  and  aggregate  planning.  In  Section  3.2  we  present  activity  operating  modes 
in  detail.  Modeling  product  transfers  in  terms  of  restrictions  on  operating  modes  is  discussed  in 
Section  3.4. 


3.  DEVELOPMENT  OF  AGGREGATE  OVERHAUL  MODEL 


The  aggregate  overhaul  model  consists  of  the  following  two  components: 

-  a  network  of  aggregate  activities 

-  a  representation  of  activity  operation. 

Its  foundation  is  the  activity  analysis  model  of  dynamic  production  networks,  which  is  reviewed 
in  the  first  section.  The  intensity  history  representation  of  activity  operation  is  retained,  but 
intermediate  product  transfers  must  be  modeled  differently  in  the  aggregate  activity  network. 

Section  3.2  discusses  activity  operation  and  demonstrates  that  key-op  network  aggregation 
has  an  effect  on  the  accuracy  of  resource  use  measurement.  This  insight  and  other  observa¬ 
tions  assist  in  the  construction  of  an  aggregate  network,  which  is  described  in  Section  3.3. 

The  special  character  of  intermediate  product  transfer  between  activities  is  illustrated  and 
its  quantitative  representation  discussed  in  Section  3.4.  Bounds  on  activity  operation  due  to 
workspace  limitations  are  dealt  with  in  Section  3.5. 

As  we  will  see  in  Chapter  4,  the  aggregate  overhaul  model  is  part  of  a  linear  programming 
iLP)  formulation  that  supports  shipyard  resource  allocation.  We  consider  computational  issues 
of  modeling  activity  operation  in  Section  3.6.  The  development  of  the  aggregate  model  is  con¬ 
cluded  in  Section  3.7  by  presenting  the  version  used  in  the  LP. 

3.1.  Review  of  Dynamic  Activity  Anaiysis 

The  theory  of  dynamic  production  networks  is  due  to  Shephard  [10].  We  present  a  special 
case,  (fymmic  activity  analysis,  as  a  starting  point  for  development  of  the  aggregate  overhaul 
model.  See  Reference  [6]  for  a  more  detailed  treatment. 

Intensity  Function 

A  production  system  is  viewed  as  a  network  of  activities  A\,A2. ...  The  system 
operates  during  an  interval  (0,  fi.  We  divide  the  interval  into  time  periods  (t— l,r],  T, 

which  are  referred  to  simply  by  their  index,  t.  The  operation  of  each  activity  A,  is  measured  by 
a  step  function  Z/(t),  /— 1,...,  T,  called  the  intensity  Junction  of  A,.  The  intensity  at  time  t 
expresses  the  (non-negative)  rate  at  which  Af  operates  during  (r— l,t]  as  measured  in  some 
physical  unit. 
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Technical  Coefficients 

An  activity  uses  resources  R\, ...  ,Rx  proportionally  to  its  intensity  function.  It  uses 
and  produces  intermediate  products,  also  proportionally  to  z,(r).  Let  the  intermediate  products 
be  denoted  by  IP/,,  A— l,...,/f.  A  product  //**  may  be  produced  or  used  by  several  activities,  or 
may  have  a  unique  producer  and  user.  The  following  technical  coefficients  of  operation  are 
given.  They  can  vary  over  time,  but  we  consider  only  the  constant  case  here.  Let 
Oict  —  amount  of  resource  R^  used  by  Aj  per  unit  intensity  of  Aj 
Cu  —  amount  of  intermediate  product  IP,,  produced  by  A,  per  unit  intensity  of  A, 

Ou  ~  amount  of  intermediate  product  IPh  used  by  per  unit  intensity  of  Aj. 

♦ 

Intensity  Bounds 

The  operating  intensity  of  activity  Ai  at  time  t  is  bounded  by  a  parameter  z,(r)  derived 
from  known  technical  limitations  on  the  operation  of  At.  Thus, 

z,(/)  <  Z/(/)  for  r-1,2,...,  r. 


Intermediate  Product  Transfer  Constraints 

In  the  dynamic  activity  analysis  model,  intermediate  products  are  produced  proportionally 
to  activity  intensity,  and  "flow"  to  other  activities  through  time.  Production  in  one  time  period 
is  assumed  available  for  use  in  the  next  period.  The  transferred  products  may  be  stored  until 
they  are  used.  Transfers  are  constrained  by  requiring  that  intermediate  product  inventories  are 
non-negative.  In  other  words,  the  amount  used  of  each  product  IP/,  by  time  t  may  not  exceed 
the  amount  produced  by  time  r-1: 

L  £  <  X  £  (3.1) 

J~l  T-l  /-I  r-1 


3.2.  Characteristics  of  Aggregate  Activity  Operation 

We  represent  an  overhaul  as  a  network  of  aggregate  activities,  and  develop  a  modified 
dynamic  activity  analysis  model  of  activity  operation.  In  this  section  we  assume  that  the  aggre¬ 
gate  network  has  been  constructed,  i.e.,  aggregate  activities  have  been  defined  and  each  key-op 
has  been  assigned  to  such  an  activity.  (Aggregation  is  discussed  in  Section  3.3.) 


3.2.1.  Activity  Operatir;  Modes 


Let  an  aggregation  of  the  key-ops  KOu....>KOi  to  activities  A\,...,As  be  given.  We  need 
to  measure  operating  intensity  in  terms  of  some  physical  unit.  The  operation  of  an  activity  is 
strongly  characterized  by  its  use  of  labor  resources.  Since  the  resources  (labor  types)  have  the 
same  physical  unit  we  use  the  rota/ resource  application.  Let 


.  .  total  amount  of  resources  applied  during  (/—!,/]  fy  activity  A, 


total  resource  requirements  of  A/ 

—  proportion  of  total  requirements  that  is  used  in  (/—!,/]  . 

The  amount  of  labor  resource  /?*  used  by  Ai  is  the  sum  of  the  amounts  used  by  the  key-ops 

assigned  to  it.  For  the  above  definition  of  intensity  the  coefficient  a/d  (see  Section  3.1)  is  given 

by  ^kh  where  the  summation  21  *s  always  assumed  to  be  over  the  key-ops  assigned  to 

/  / 

Aj.  Total  resource  use  by  A/  is  denoted  by  ai  =  ^aid“^  bi,  where  = 

k  I  k 

resource  use  by  KOi,  and  the  summation  X  ‘s  over  all  resources  /?*,  A:«1,...,A. 

A; 

We  restrict  the  operation  of  .4,  to  those  time  periods  in  which  the  key-ops  assigned  to  Ai 
can  operate.  This  window  of  operation  is  denoted  by  (5/,Ffl,  where 

Sj  -  min  ES,  and  Fi  —  max  LF,  . 

KO,^A,  KO,^A, 

The  operation  of  Aj  within  its  window  is  represented  by  its  operating  mode 
z,(5,),2/(5,-1-1),...,Z/(F,).  (For  notational  convenience  we  include  r,(5,),  although  z,(S,)— 0  by 
construction.)  We  denote  the  operating  mode  by  OA/,={z,(f)},.  Let 


2iU)  S  X  z,(t)  (3.2) 

r-S, 

be  the  cumulative  operating  intensity,  i.e.,  the  proportion  of  resources  used  up  to  time  t.  It 
satisfies  Z,(5/)— 0  and  Z,(F/)-l.  The  operating  mode  of  Aj  can  also  be  expressed  in  terms  of 
the  time  history  of  cumulative  intensity,  {Z<(r)),.  (Throughout  this  paper  we  will  interchange¬ 
ably  refer  to  {z/(/)) ,  and  [Z,(t)] ,  as  the  operating  mode  of  A/.) 


3.2.2.  Modeling  of  Resource  Use 

Let  Xiciit)  be  the  amount  of  resource  /?*  applied  to  activity  Aj  during  (r-1,/],  so  that 

Xki(t)  -  • 

Consider  the  activity  resource  load  arising  from  a  given  schedule  S  of  key-op  start  times.  Let 
xu(t)  be  the  amount  of  R*  used  by  Aj  at  time  r,  and  let  zfit)  be  the  intensity  of  Aj  at  t,  as 
derived  from  start  schedule  S.  From  (2.2)  we  can  compute  x^it)  as 

/  /€A(S,/) 

where  A(5,/)  =  {/  I  KOi^Ai,  Si<  F/}  is  the  index  set  of  all  key-ops  within  Ai  that  operate 
at  r,  given  S.  The  intensity,  given  S,  is  computed  as 

total  resource  amount  used  by  A/  during  (t— l,t],  given  S 
'  total  resource  use  by  A/ 


1 40) 


£  X  X*'"  ^ 

k  KMS,t)  “/  /€A(S./)  0/ 


We  are  interested  in  determining  when  resource  use  is  modeled  accurately  in  terms  of 
intensities.  Use  of  /?*  by  Aj  during  (r— l,r],  as  derived  from  S,  is  x^iit).  Use  of  /?*,  as 
modeled,  is  auzfit)-  Equating  the  two  we  have 


X^iU)  -  OkiZfit)  £  hi2i  -  L  Oki  z, 

l€A{S,i)  /€A(5./) 


In  general,  equality  will  occur  only  if 

bki  -  ^  . ^  • 

Of  b,  a, 

Consequently,  overhaul  resource  use  derived  from  a  given  schedule  5  is  not  modeled  accu¬ 
rately  if  the  resource  mixes 


I*- 


vary  among  key-ops  KOi  assigned  to  the  same  activity. 
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3.2.3.  Intensity  Bounds 

Consider  the  whole  range  of  feasible  key-op  start  time  schedules  between  the  early  and 
late  schedules  ES  and  LS.  The  intensity  of  activity  Aj  at  time  t  would  be  highest  if  all  the 
key-ops  assigned  to  Aj  that  could  operate  at  t  actually  did.  Let  us  define  the  intensity  bound 
z,(r)  accordingly: 

total  resource  use  during  (f— 1,/] 

_  by  key— ops  KOi  within  A,  for  which  ES/  <  /  <  L/) 

'  total  resource  use  by  A, 

The  bound  will  overstate  the  highest  possible  intensity  if  some  of  the  key-ops  assigned  to  Aj 
are  in  series.  In  Section  3.5.1  we  demonstrate  that  this  bound  is  not  very  effective  and  discuss 
tighter  intensity  bounds. 

3.2.4.  Window  Curves 

The  early  and  late  key-op  start  schedules  ES  and  LS,  defined  in  Section  2.4,  are  the  two 
extremes  for  overhaul  execution  as  represented  by  the  key-op  network.  We  introduce  an 
equivalent  notion  for  the  aggregate  activity  network.  Let  us  define  the  early  operating  mode 
OMi^lZjHt)] ,  of  At  by  setting  S^ES  in  (3.3),  as  shown  below: 

Zfit)  =  X  zfir)  =  2  —Zi- 

T-s,  /eA(£S,T) 

The  late  operating  mode  OMt  is  defined  analogously. 

If  the  key-op  aggregation  were  "perfect”,  i.e.,  for  each  At,  the  key-ops  within  At  had  the 
same  resource  mix,  then  the  following  would  hold  for  any  feasible  operating  mode  of  At- 

the  proportion  of  total  resources  used  by  ^4/  up  to  time  t  could  not  exceed  the  proportion 
used  in  the  early  mode:  ZtU)  <  Z^t) 

the  proportion  used  by  At  after  t  could  not  exceed  the  proportion  used  in  the  late  mode 
after  t:  1-Z,(r)  <  \-Zfit). 

Although  the  key-op  aggregation  is  not  likely  to  be  "perfect",  it  is  nevertheless  reasonable  to 
constrain  OM,  by 


ZtU)  <  Z,U)  <  Z,Ht)  for  t^St . Ft  . 


(3.4) 
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(For  f— S,  and  r— F,  these  constraints  are  trivially  satisfied.) 

Constraints  of  type  (3.4)  certainly  constrain  activity  operation.  However,  further  con¬ 
straints  are  required;  for  example,  we  need  to  prevent  an  activity  from  operating  early  (in  the 
model)  although  its  predecessor  operates  late.  Section  3.4  addresses  this  issue. 

We  refer  to  the  early  and  late  cumulative  intensity  curves  as  window  curves,  since  all 
modes  of  activity  operation  must  lie  between  them.  Exhibit  3. 1  (a)  shows  typical  early  and  late 
intensity  curves,  along  with  the  intensity  bound  curve  z,(/).  The  cumulative  intensity  curves 
are  shown  in  Exhibit  3.1(b). 

At  this  point  it  is  convenient  to  present  an  interpretation  of  the  area  between  the  window 
curves,  which  we  denote  by  o- ,.  It  can  be  computed  as 

F, 

<r,  S  £  ZfU)  -  ZtU)  .  (3.5) 

t—Sj 

The  magnitude  of  is  clearly  a  measure  of  the  latitude  of  operation  of  activity  A/.  In  fact,  it 
can  be  interpreted  as  the  slack  of  A/,  since  it  can  be  shown  (by  the  definition  of  Zfit)  and 
Z/<r))  that 


where  cr/  is  the  slack  of  key-op  KOi  (see  Section  2.4.1).  The  area  between  the  curves  is  thus 
the  weighted  average  of  the  slacks  of  the  key-ops  within  At. 

3.3.  Aggregate  Activity  Network  Construction 

The  aggregate  activity  network  is  a  management-level  representation  of  a  ship  overhaul. 
It  identifies  major  overhaul  components  and  the  interaction  between  them.  The  network  is  an 
aggregation  of  the  key-op  network  in  the  sense  that  each  key-op  is  assigned  to  an  aggregate 
activity.  We  seek  to  construct  the  network  in  a  way  that  resource  use  can  be  modeled  accu¬ 
rately. 

We  first  review  important  observations  about  the  aggregate  network  made  in  earlier  sec¬ 
tions.  Then,  in  Section  3.3.2,  guidelines  for  network  construction  are  presented.  In  Section 

3.3.3,  we  look  at  the  types  of  intermediate  product  transfers  that  occur.  Finally,  we  present  in 
Section  3.3.4  an  aggregate  network  constructed  from  actual  ship  overhaul  data. 
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3.3.1.  Review  of  Earlier  Observations 

Resource  Mix:  In  Section  3.2.2  we  saw  that  the  less  the  variation  of  resource  mix  among  key- 
ops  within  an  activity,  the  more  accurately  resource  use  of  the  aggregate  activity  will  be 
represented. 

Key  Events:  We  identified  key  events  as  control  points  for  transfer  of  intermediate  products 
(Section  2.3).  Important  restraining  events  should  be  included  in  the  aggregate  network  since 
they  represent  an  event-based  transfer  of  product  between  activities.  Some  monitoring  events 
will  be  implicit  in  the  network  when  they  refer  to  the  completion  of  intermediate  product 
transfer  between  two  aggregate  activities. 

Work  Breakdown  Criteria:  In  Section  2.5  we  saw  that  the  level  of  detail  which  characterized  the 
key-op  network  must  be  reduced.  In  particular,  we  cannot  distinguish  all  different  technical 
systems  and  work  locations.  While  the  strict  precedence  relationships  between  key-ops  are  not 
captured  in  the  aggregate  model,  we  do  need  to  extract  as  much  information  as  possible  about 
the  operating  alternatives  of  key-ops.  Clearly,  resource  use  characteristics  remain  important  as 
a  criterion  for  activity  definition. 

3.3.2.  Guidelines  for  Network  Construction 

To  construct  the  aggregate  activity  network  we  must  analyze  the  structure  of  the  key-op 
network.  This  will  allow  us  to 

-  define  aggregate  activities  (network  nodes) 

-  identify  intermediate  product  transfers  between  activities  (network  arcs). 

This  analysis  is  not  easily  systematized.  It  certainly  does  not  proceed  in  a  sequential  order  of 
steps.  Rather,  it  is  an  iterative  process  by  which  the  network  is  continually  refined. 

Exhibit  3.2  shows  the  key-op  network  for  a  simple  overhaul.  (The  lines  around  pairs  of 
nodes  should  be  ignored  initially.)  Although  it  is  unrealistically  straightforward  (and  made  to 
measure)  it  does  help  clarify  the  steps  presented  below.  The  example  contains  four  technical 
systems.  Two  are  mechanical  (Ml, A/2),  the  other  two  electrical  (£1,£’2).  Each  system 
overhaul  involves  inspection  (/),  repair  (R),  test  (D,  and  work  space  clean-up  (C).  All 
inspections  must  be  completed  before  any  repairs  can  be  started.  Clean-up  and  test  can  both 
start  after  repair  is  finished,  and  they  are  assumed  not  to  interfere  with  each  other.  Repair  and 
test  of  each  system  involve  the  same  labor  type,  but  in  different  quantities  and  rates.  All 
clean-ups  require  the  same  labor  type. 


EXHIBIT  3.2 


EXAMPLE  -  KEY-OP  NETWORK 
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EXHIBIT  3.3 


EXAMPLE  -  AGGREGATE  ACTIVITY  NETWORK 


The  following  steps  describe  the  process  of  developing  the  aggregate  network.  As  men¬ 
tioned  above,  some  iteration  of  these  steps  is  required. 

Step  1;  Identify  major  restraining  key  events  and  how  they  restrict  the  overhaul  of  each  techni¬ 
cal  system. 

Example:  As  mentioned,  the  "Complete  Inspection”  event  succeeds  all  inspections, 
and  precedes  all  repairs. 

Step  2:  For  subnetworks  between  key  events,  group  key-ops  within  similar  technical  systems: 
Example:  We  identify  four  groups: 

-  inspection  of  mechanical  systems  (/A/1,2) 

-  inspection  of  electrical  systems  (/£1,2) 

-  overhaul  of  mechanical  systems  (/IA/1,2;  CA/1,2;  rMl,2) 

-  overhaul  of  electrical  systems  (/?£'I,2;  C£'l,2;  7'£1,2). 

Step  3:  Within  each  group,  distinguish  between  different  labor  shop  emphases.  Identify 
differences  in  timing  and  resource  use  rate  among  the  tasks  with  similar  labor  shop  emphasis. 

Example:  Exhibit  3.2  shows  the  resulting  groups  of  tasks.  Note  that  repair  and  test 
are  distinct  since  they  use  the  same  labor  type  but  at  different  times  and  at  different 
rates. 

Step  4:  Connect  groups  to  show  intermediate  product  transfers.  (The  next  section  discusses 
this  in  more  detail.) 

Example:  Network  arcs  between  the  groups  in  Exhibit  3.2  are  easy  to  identify.  Exhi¬ 
bit  3.3  shows  the  resulting  aggregate  activity  network. 

Step  S:  Identify  monitoring  key  events  and  connect  activities  with  them. 

Example:  Suppose  mechanical  repairs  are  to  be  monitored  closely.  Add  an  event 
node  and  connect  the  activity  with  it,  as  in  Exhibit  3.3. 

3.3.3.  Intermediate  Product  Transfer  Arcs 

Analysis  of  the  intermediate  product  transfers  within  a  preliminary  aggregate  network 
(developed  according  to  the  guidelines  in  Section  3.3.2)  may  lead  to  revisions  in  the  aggrega¬ 
tion,  or  further  aggregation.  The  modeling  of  product  transfers  for  various  types  of  key-op 
aggregation  is  discussed  below. 

An  arc  connects  two  aggregate  activities  A  and  £  if  a  key-op  in  A  has  a  successor  in  B, 
or  equivalently,  if  intermediate  product  is  transferred  from  a  key-op  in  /4  to  a  key-op  in  B.  As 
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EXHIBIT  3.4 

DISTINCT  AND  SHARED  INTERMEDIATE  PRODUCT  OUTPUT 


stated  in  Section  2.2,  a  key-op  produces  a  distinct  product  for  each  of  its  successor  key-ops. 

A  particular  key-op  aggregation  may  result  in  transfers  from  key-ops  in  A  to  key-ops 
within  many  other  activities.  We  could  ignore  unimportant  transfers  from  activity  A.  Such  a 
situation  may  indicate,  however,  that  the  aggregation  could  be  improved.  The  aggregate  activi¬ 
ties  represent  major  overhaul  components,  so  that  only  a  few  transfer  arcs  from  each  activity  to 
other  activities  should  be  necessary. 

Activity  A  produces  intermediate  products  for  its  successors.  As  is  discussed  below,  it 
may  produce  one  product  which  is  shared  by  its  successors,  or  a  distinct  product  for  each  suc¬ 
cessor.  A  given  operating  mode  of  A  implies  a  distribution  of  intermediate  product  output 
through  time.  By  the  nature  of  the  operating  mode  model,  this  distribution  is  identical  for  all 
outputs  that  A  produces. 

For  convenience  of  exposition,  let  activity  A  have  two  successors  B  and  C,  as  in  Exhibit 
3.4(a).  (The  analysis  that  follows  can  be  extended  to  more  than  two  successors.)  We  study  the 
product  output  of  A  by  considering  the  key-op  subnetwork  underlying  the  activities  A,  B,  and 
C. 

Distinct  Products 

Suppose  A,  B,  and  C  are  aggregated  from  the  key-op  subnetwork  in  Exhibit  3.4(b).  Each 
of  the  key-ops  in  A  produces  distinct  products  for  its  successors  in  B  and  C.  Accordingly,  the 
intermediate  products  for  B  and  C  are  considered  to  be  distinct. 

Shared  Intermediate  Product  Outputs 

Now  suppose  they  are  aggregated  as  in  Exhibit  3.4(c).  Let  us  look  at  an  example.  Sup¬ 
pose  the  key-ops  in  A  are  removals  of  four  components  within  the  same  technical  system.  Two 
of  the  components  must  then  be  painted  iB),  the  other  two  lubricated  (C).  We  can  plan  the 
component  removals  in  A,  i.e.,  its  use  of  resources  over  time,  independently  of  the  order  of 
removals.  Thus,  for  resource  use  planning,  the  removals  can  be  considered  as  indistinguish¬ 
able,  and  also  their  output. 

We  therefore  assume  that  only  one  intermediate  product  is  produced  by  A,  which  is  then 

shared  by  B  and  C.  This  is  indicated  graphically  in  Exhibit  3.4(d).  As  will  be  discussed  in 

% 

Section  3.4,  the  operation  of  B  and  C  must  be  constrained  so  as  to  properly  share  the  product 
output  of  A. 
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DISTINCT  AND  POOLED  INTERMEDIATE  PRODUCT  INPUT 
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Pooled  Intermediate  Product  Outputs 

Analogous  arguments  can  be  made  if  activity  A  has  multiple  predecessors.  A  given 
operating  mode  of  A  implies  a  particular  distribution  of  intermediate  product  input.  We 
assume  that  this  distribution  is  identical  for  all  distinct  inputs  that  A  uses.  Suppose  it  has  two 
predecessors  D  and  £,  as  in  Exhibit  3.5(a).  The  intermediate  products  from  D  and  E  are  con¬ 
sidered  distinct  if  the  underlying  key-op  subnetwork  is  similar  in  structure  to  Exhibit  3.S(b). 
We  say  that  D  and  E  pool  their  outputs  if  the  key-op  subnetwork  is  as  in  Exhibit  3.5(c). 
Activity  A  then  receives  the  pooled  output  as  a  single  input,  as  indicated  in  Exhibit  3.5(d). 

Consider  the  aggregate  network  in  Exhibit  3.3.  The  clean-up  activities  are,  by  assump¬ 
tion,  similar  in  content.  The  intermediate  product  that  each  clean-up  activity  receives  is  a 
workspace  that  is  to  be  put  back  in  order.  In  such  a  case  we  can  merge  the  two  clean-up  activi¬ 
ties.  The  product  input  consists  of  a  pool  of  workspaces  that  are  "produced"  by  the  repair  activi¬ 
ties.  Exhibit  3.6  shows  the  aggregate  network  after  the  activity  merger.  (This  portion  of  the 
example  aggregation  was  not  included  in  Section  3.3.2  to  avoid  confusion.) 

3.3.4.  Aggregate  Network  from  Overhaul  Data 

An  aggregate  activity  network  for  an  actual  ship  overhaul  was  constructed.  The  original 
key-op  network  contained  approximately  1150  key-ops.  From  this  network  a  more  aggregate 
network  was  developed  with  approximately  430  key-ops.  These  430  more  aggregate  key-ops 
were  in  turn  aggregated  into  39  activities.  A  list  of  restraining  events  is  given  in  Exhibit  3.7, 
and  the  12  largest  labor  shops  are  listed  in  Exhibit  3.8.  Exhibits  3.9  and  3.10  show  the  aggre¬ 
gate  network  and  activity  data,  consisting  of 

-  the  number  of  key-ops  assigned  to  activity  Aj 

-  its  "lead  shop"  (see  Section  2.2) 

-  its  total  labor  requirement,  Oj  (in  man-days) 

-  the  range  of  its  operating  window,  (S,,/"/]  (in  two  week  units). 

Three  main  groups  of  technical  systems  were  identified,  namely  Mechanical,  Structural, 
and  Electrical  &  Electronic.  Within  each  group,  differences  in  timing  and  labor  use  rate  had  to 
be  taken  into  account,  for  example: 

some  structural  overhauls  could  take  place  at  any  time  between  docking  and  undocking 

(activity  .4g),  so  they  could  not  be  aggregated  together  with  the  removal,  repair,  and  rein¬ 
stallation  sequence  (A2,A3,A^  for  the  structural  component  overhauls 
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EXAMPLE  -  REVISED  AGGREGATE  ACTIVITY  NETWORK 


EXHIBIT  3.  7  OVERHAUL  DATA  -  LIST  OF  RESTRAINING  EVENTS 


Code  Key  Event 


Occurrence  Time 
(two  week  units) 


601 

Start  Overhaul 

0 

514 

Complete  Lagging  Removal 

2 

602 

Dock  Ship 

5 

604 

Undock  Ship 

14 

606 

Prepare  Engine  &  Boiler  Rooms  for  Test 

16 

609 

Complete  Production  Work 

20 

EXHIBIT  3. 8  OVERHAUL  DATA  -  LIST  OF  LABOR  SHOPS 


No. 

Shop  Name 

Total  Req’ts 
(man-days) 

1 

Pipehtting 

5913 

2 

Mechanical  Group  -  Shipboard 

5111 

3 

Mechanical  Group  -  Shore 

4307 

4 

Electrical 

3038 

5 

Painting 

2999 

6 

Electronics 

2796 

7 

Boilermakers 

2309 

8 

Weld  &  Burn 

2289 

9 

Structural  Group  I 

1392 

10 

Structural  Group  II 

1333 

11 

Shipwright 

638 

12 

Rigging 

536 

TOTAL 

32660 
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L  EXHIBIT  3.10  OVERHAUL  DATA  -  LIST  OF  ACTIVITIES 

■ 


/■ 

Activity  Aj 

No.  of 

Lead 

Oi 

5.- 

Fi 

Key-ops 

Shop 

1 

Remove  Lagging,  Engine  &  Boiler  Rooms 

5 

1 

500 

0 

2 

2 

Remove  Structural  Components  602-604 

11 

2 

105 

5 

9 

3 

Repair  Structural  Components  602-604 

18 

5 

508 

6 

13 

4 

Reinstall  Structural  Components  602-604 

13 

8 

152 

10 

14 

5 

Remove  Mechanical  Components  602-604 

8 

2 

127 

5 

9 

6 

Repair  Mechanical  Components  602-604 

13 

2 

505 

7 

12 

7 

Reinstall  and  Test  Mechanical  Components  602-604 

10 

2 

217 

9 

14 

8 

Misc.  Mechanical  Overhauls  602-604 

18 

2 

548 

5 

14 

9 

Misc.  Electrical  Overhauls  602-604 

32 

4 

436 

5 

14 

10 

Misc.  Structural  Overhauls  602-604 

18 

8 

660 

5 

14 

11 

Misc.  Removals  514-604 

10 

2 

52 

1 

6 

12 

Misc.  Repairs  514-604 

17 

3 

495 

2 

13 

13 

Misc.  Reinstallations  &  Test  514-604 

19 

2 

197 

6 

14 

14 

Overhaul  Tanks  and  Voids 

40 

5 

1668 

1 

14 

15 

Overhaul  Air  Systems 

44 

1 

885 

0 

16 

16 

Misc.  Removals  601-609 

29 

2 

205 

0 

12 

17 

Misc.  Repairs  601-609 

33 

2 

764 

5 

13 

18 

Misc.  Reinstallations  601-609 

29 

2 

696 

8 

19 

19 

Misc.  Component  Overhauls  601-609 

S3 

1 

1917 

0 

19 

20 

Remove  Electrical  System  Components 

45 

4 

331 

0 

9 

21 

Repair  Electrical  System  Components 

84 

6 

2597 

1 

15 

22 

Reinstall  Electrical  System  Components 

61 

4 

1046 

3 

16 

23 

Test  Electrical  System  Components 

45 

6 

1104 

5 

20 

24 

Post  Undocking  Tests 

23 

5 

190 

14 

19 

25 

In-place  Overhaul  Engine  Room  Components 

51 

2 

1876 

1 

15 

26 

Remove  Engine  Room  Components 

68 

2 

575 

1 

10 

27 

Repair  Engine  Room  Components 

92 

3 

3207 

2 

14 

28 

Reinstall  Engine  Room  Components 

70 

2 

1193 

3 

15 

29 

Test  Engine  Room  Components 

44 

2 

1064 

7 

16 

30 

In-place  Repair  Engine  Room  Components 

14 

2 

387 

3 

15 

31 

Overhaul  Vents  &  Bilges 

11 

9 

1385 

1 

14 

32 

Repair  &  Reinstall  Lagging 

7 

1 

1577 

5 

19 

33 

Inspect  Boiler 

8 

7 

467 

1 

4 

34 

Remove  Boiler  Room  Components 

11 

7 

624 

2 

9 

35 

Repair  Boiler  Room  Components 

•15 

7 

813 

3 

12 

36 

Reinstall  Boiler  Room  Components 

16 

7 

1161 

5 

15 

37 

Test  Boiler  Room  Components 

21 

7 

733 

9 

16 

38 

In-place  Repair  Boiler  Room  Components 

32 

7 

1579 

3 

16 

39 

System  Test  Turbine  &  Boiler 

9 

2 

114 

16 

19 

TOTALS 

1147 

32660 

rwo  engine  room  in-place  repair  activities  were  defined  (A  25  and  i^ao)  since  some  in-place 
repairs  succeeded  component  removals,  but  others  did  not. 


Intermediate  products  have  unique  producers  and  users,  except  for  two  cases; 

the  bilge  and  ventilation  overhauls  in  the  engine  and  boiler  rooms  were  combined  since 
they  are  indistinguishable  (^31);  this  activity  shares  its  output  with  the  test  activities  in 
engine  and  boiler  rooms  (>429,^437) 

lagging  (asbestos  insulation)  removal  in  the  engine  and  boiler  rooms  has  to  be  completed 
before  component  removals  can  begin,  as  key  event  514  indicates.  Once  the  component 
removals  (A  26, A  34)  have  been  completed,  the  lagging  can  be  repaired  and  eventually  rein¬ 
stalled  (.432).  The  removal  activities  ^426  and  A  34  pool  their  output  for  A  32. 

Note  that,  for  example,  the  engine  room  removal  activity  (A 2^  produces  distinct  inter¬ 
mediate  products  for  its  successors  .4  27  and  ^430.  While  A  22  is  the  shop  repair  of  removed  com¬ 
ponents,  >430  is  the  in-place  repair  of  the  system  components  not  removed.  The  underlying 
key-op  network  resembles  that  in  Exhibit  3.4(b). 

Monitoring  events  have  not  been  included  in  Exhibit  3.9.  They  correspond  to  the  com¬ 
pletion  of  one  or  more  activities.  For  example,  shop  repairs  of  engine  and  boiler  room  com¬ 
ponents  are  monitored  together,  so  that  ^427  and  ^435  both  would  lead  to  a  single  monitoring 
event  node. 

The  activity  window  curves  were  computed  for  given  key  event  dates.  Exhibit  3.7  shows 
the  restraining  event  dates,  and  Exhibit  3.10  the  activity  window  ranges.  They  are  all  in  units 
of  ten  working  days.  (The  reason  for  this  becomes  clear  in  Section  3.7.) 

The  aggregate  network,  as  it  was  constructed,  shows  too  much  detail  in  some  places, 
perhaps,  and  not  enough  in  others.  To  some  extent  this  is  due  to  the  authors'  lack  of  familiar¬ 
ity  with  the  actual  overhaul.  On  the  other  hand,  the  aggregation  is  only  as  good  as  the  underly¬ 
ing  key-op  network.  In  fact,  the  current  method  of  developing  key-op  networks  does  not  ade¬ 
quately  take  labor  use  into  account.  Research  is  underway  to  improve  the  key-op  network 
development  methodology. 


3.4.  Representation  of  Intermediate  Product  Transfer 

We  are  interested  in  describing  the  feasible  distributions  of  resource  use  by  an  overhaul. 
Each  distribution  represents  a  particular  set  of  operating  modes  of  the  activities  within  the 
overhaul.  In  Section  3.2  we  developed  constraints  on  the  operation  of  the  activities  by  consid¬ 
ering  each  activity  separately.  Unless  we  constrain  the  operation  of  all  activities  to  be  con¬ 
sistent  with  one  another,  our  model  of  overhaul  resource  use  will  be  inadequate  and  inaccurate. 

The  operation  of  the  activities  will  be  consistent  if  intermediate  product  transfers  are 
feasible,  i.e.,  intermediate  products  are  available  when  they  are  required.  At  the  key-op  level 
this  simply  means  that  key-ops  must  finish  before  their  successors  start.  However,  at  the  aggre¬ 
gate  activity  level  it  is  not  possible  to  represent  product  transfers  in  such  detail;  rather,  we  must 
model  the  transfers  by  constraining  the  set  of  operating  modes  appropriately.  Developing  such 
constraints  is  the  topic  of  this  section.  We  begin  by  presenting  a  general  model  of  intermediate 
product  transfers. 

3.4.1.  General  Model  of  Intermediate  Product  Transfers 

The  operating  mode  OAf/-{Z/(r)},  of  an  aggregate  activity  A/  determines  its  distribution 
of  resource  use.  In  addition,  OM/  implies  a  particular  distribution  of  the  intermediate  products 
used  and  produced  by  A/.  The  activity  may  be  the  sole  user  or  producer  of  an  intermediate 
product,  or  one  of  several  users  or  producers. 

We  denote  the  intermediate  products  by  /Pi,  . .  .  ,IPh-  As  in  Section  3.1,  let 
a  hi  —  amount  of  IPh  that  Aj  uses 
Chi  “  amount  of  IPh  that  A/  produces  . 

Since  the  total  amounts  used  and  produced  of  each  intermediate  product  are  equal,  we  can 
assume  the  coefficients  to  be  normalized  as  follows: 

S  N 

/-I  /-I 

As  mentioned  in  Section  3.3.3,  we  also  assume  that  the  distribution  of  intermediate  pro¬ 
duct  use  by  Ai  is  identical  for  all  IPh  for  which  ahi>0.  Let  us  denote  their  common  input  distri- 
butionby  {/,(/)}„  where  for  r-1, ....  f. 
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//(r)  -  proportion  of  used  by  /4,  up  to  time  t,  given  OA/,  (applying  to  all  /P*, 

Similarly,  let  {0/(r)},  be  the  common  output  distribution  of  intermediate  products  produced  by 
Ai,  where  for  /—I ,  P, 

Oi(t)  —  proportion  of  C/,,  used  by  Aj  up  to  time  r,  given  OM,  (applying  to  all  IP/,,  A—l, 

Outside  of  the  operation  window,  the  following  holds: 

I,(t)  -  0,(/)  -  0  r  <  5, 

Ii(t)  -  Oiit)  -  1  Fi. 

The  input  and  output  distributions  of  A,  are  functions  of  the  operating  mode  of  A,.  In  the 
dynamic  activity  analysis  model,  for  example, 

Ii(t)  -  Z,(/)  ,  Oiit)  -  Ziit-l)  . 

The  operating  modes  of  all  activities  are  consistent  with  one  another  if,  for  each  inter¬ 
mediate  product  IP/,  and  each  time  period  r,  total  use  of  IP/,  up  to  t  (as  induced  by  the  operat¬ 
ing  modes)  does  not  exceed  the  induced  total  production  of  IP/,  up  to  t.  This  is  expressed  as 
follows: 


f  <  £  CMOiit)  /t-1 . H;  r-1 . T.  (3.7) 

j~i  /-i 

Note  that  this  reduces  to  (3.1)  for  the  dynamic  activity  analysis  model.  In  the  aggregate  activity 
network  the  following  three  cases  of  the  above  constraints  can  occur,  depending  on  the  number 
of  users  and  producers  of  each  intermediate  product: 

(1)  Singk  Producer  and  User 

IPh  is  produced  only  by  A,  (c^/— 1)  and  used  only  by  i4y  (5^1): 

Ijit)  <  Oiit)  .  (3.8a) 


(2)  Single  User,  Pooled  Production 

IP),  is  used  only  by  A j  (a/^1)  but  is  produced  by  multiple  predecessors  of  A j  (those  activities 
Ai  for  which  Ci,i>0): 

<  I  c,iOiit)  . 


(3.8b) 


1 
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(3)  Single  Producer,  Shared  Use 

IPh  is  produced  only  by  Aj  1)  but  is  shared  by  multiple  successors  of  Ai  (those  activities 
Aj  for  which  ai^>0): 

X  at,jIjU)  <  0,(f)  .  (3.8c) 

7-1 

Ideally,  we  would  like  to  hnd  explicit  representations  of  the  relationship  between  use  and 
production  of  intermediate  product  and  the  operating  mode  of  each  aggregate  activity.  Con¬ 
straints  (3.8)  could  then  be  stated  directly  in  terms  of  operating  intensities.  In  Section  3.4.2  we 
study  this  relationship,  but  conclude  that  the  correspondence  between  resource  use  and  inter¬ 
mediate  product  input  and  output  cannot  be  easily  described  in  the  aggregate  overhaul  model. 
As  an  alternative,  we  present  constraints  in  Section  3.4.4  that  describe  the  set  of  consistent 
operating  modes  by  comparing  the  "relative  progress"  of  the  activities.  The  resulting  relative 
progress  transfer  constraints  turn  out  to  be  analogous  to  those  in  (3.8). 

3.4.2.  Product  Transfer  Characteristics 

Given  a  key-op  start  time  schedule  we  approximate  the  distributions 

{//•^r)),  and  {0,^r)},  induced  by  S  in  terms  of  resource  quantities.  They  will  be  compared  with 
(Zf'^t)}  t  using  examples  from  actual  overhaul  dau. 

A  key-op  KOi  within  A,  uses  its  intermediate  product  input  when  it  starts.  Let  us  meas¬ 
ure  the  input  quantity  by  the  amount  of  resources  that  is  committed  when  KOi  starts,  namely 
bi.  We  approximate  the  distribution  of  intermediate  product  use  by  the  distribution  of 
resources  committed  by  Ai.  The  proportion  of  intermediate  products  used  is  thus  taken  as  the 
proportion  of  resources  committed: 

ifU)  -  Z  —  ,  whereriS,t)  =  [I  I  S,  <  t}  . 

iins,t) 

Recall  that  the  input  distributions  of  all  intermediate  products  used  by  A,  are  assumed  to  be 
identical  (and  equal  to  [I fit)},).  To  avoid  complications  due  to  multiple  product  inputs  we  will 
compare  {/j^t)) ,  with  (Zy'^f)} ,  for  an  activity  from  the  overhaul  data  which  has  only  one  prede¬ 
cessor,  i.e.,  one  intermediate  product  input. 

Analogously,  a  key-op  KOi  within  A,  produces  its  intermediate  product  output  when  it 
finishes,  and  we  measure  the  output  quantity  by  the  amount  of  resources  that  is  released  when 
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EXHIBIT  3.11 


RESOURCE  USE  VS.  INTERMEDIATE  PRODUCT  INPUT  AND  OUTPUT 
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KOi  finishes,  namely  6/.  The  proportion  of  intermediate  product  produced  is  approximated  by 
the  proportion  of  resources  released; 

OfU)  -  L  —  ,  M/hereUSj)  =  {  /  1  KOi^A^,  S/  +  D,  <  t}  . 

/eA(S,/) 

As  before,  we  will  compare  {Of(/)),  with  for  a  given  schedule  S,  choosing  an  activity 

with  only  one  successor. 

Exhibit  3.11  shows  and  {0,^f)},  for  an  activity  from  the  overhaul  data 

(activity  A  27  in  Exhibit  3.9)  which  does  have  only  one  predecessor  and  one  successor.  In  Exhi¬ 
bit  3.11(a),  S  is  chosen  to  be  the  early  schedule  £S;  in  Exhibit  3.11(b),  5—1.5.  We  observe 
that  intermediate  product  input  and  output  are  certainly  not  proportional  to  resource  use,  as  the 
dynamic  activity  analysis  model  assumes.  Also,  there  is  no  constant  time  lag  or  resource  use 
lag  between  {/,'^r)}, and  {Z('*^(r)}„  or  between  {Z,^r)),  and  {Of(f)),. 

To  illustrate  the  transfer  of  intermediate  product  we  introduce  the  following  notion:  an 
activity  Aj  is  said  to  operate  tightly  mth  its  predecessors  (i.e.,  suppliers  of  intermediate  product) 
if  it  uses  its  intermediate  product  inputs  as  soon  as  they  are  produced.  At  the  key-op  level,  Aj 
operates  tightly  with  its  predecessors  if  all  key-ops  within  A j  start  immediately  upon  completion 
of  their  predecessor  key-ops. 

If  Aj  has  a  predecessor  At,  but  no  other  activities  precede  Aj  or  succeed  .4,,  then  the  fol¬ 
lowing  should  hold  when  A j  operates  tightly  with  A,: 

t~Si . /■ . 

Referring  to  the  overhaul  data  again,  the  activity  just  discussed  was  chosen  so  that  its  successor 
has  no  other  predecessors.  Exhibit  3.12  shows  {0/(r)),  and  (//(f)),  for  5- £5  and  5—1.5. 
(Note  that  for  the  early  and  late  schedules,  all  activities  operate  tightly  with  their  predecessors.) 
We  observe  that  the  curves  are  quite  close.  Differences  inevitably  occur  when,  for  example, 
KO„  in  Aj  succeeds  KOi  in  A,,  but  their  respective  contributions  6/ a,  and  bjaj  to  resource 
use  of  A,  and  Aj  are  unequal. 

Exhibit  3.12  also  shows  the  operating  modes  {Z/(f)},  and  {Z/(f)},  for  S^ES,  LS.  There 
is  no  constant  time  lag  or  resource  use  lag  between  the  two.  Furthermore,  while  all  transfers 
take  place  in  the  overlap  (5y,F,l  of  the  windows  of  Aj  and  Aj,  the  distribution  of  product 
transfer  within  the  overlap  can  vary  strongly.  Note  that  the  transfers  determine  the  operation 


EXHIBIT  3.12 


TIGHT  OPERATION  OF  ACTIVITY  WITH  ITS  PREDECESSOR 
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of  A j  throughout  its  window,  not  only  in  the  overlap. 

In  conclusion,  the  example  from  the  overhaul  data  illustrates  that  intermediate  product 
input  and  output  is  related  to  resource  use  in  a  complicated  non-linear  maimer.  The  same  con¬ 
clusion  holds  for  the  relation  between  the  operating  modes  of  A/  and  Aj  when  Aj  operates 
tightly  with  A/. 


3.4.3.  Relative  Progress  of  Activity  Operation 

Let  us  suppose  an  activity  Af  has  a  successor  Aj,  but  that  no  other  activity  succeeds  Ai  or 
precedes  Aj.  Our  objective  is  to  describe  the  operating  modes  OMj—{Zj(t)] ,  that  are  con¬ 
sistent  with  a  given  operating  mode  OA/,— {Z/(/)),  of  A,. 

Suppose  we  could  determine  the  operating  mode  of  ^4^  when  Aj  operates  tightly  with  the 
given  mode  OM,  of  Ai\  let  us  denote  it  by  OAf/— {Z/(i)),.  The  tight  operating  mode  of  Ajis 
the  earliest  feasible  mode  of  Aj,  given  OMi.  An  operating  mode  OMj  will  be  consistent  with 
OAf/  if,  for  all  time  periods,  OMj  does  not  use  more  resources  than  OMj does,  i.e., 

Zjit)  <  ZjXt)  t^Sj . Fj  .  (3.9) 


Thus,  if  we  can  determine  OMj  in  terms  of  OA/},  the  operating  modes  OMj  consistent 
with  OMj  can  be  described.  Note  that,  at  the  key-op  level,  there  may  be  many  key-op 
schedules  that  induce  an  aggregate  activity  operating  mode  OM,.  This  would  imply  that  there  is 
no  unique  OM],  since  each  such  schedule  for  Ai  might  induce  a  distinct  tight  operating  mode 
for  Aj.  We  will  assume  that  the  differences  between  such  modes  of  .4^  are  insignificant. 

In  the  last  section  we  observed  that  OM]  is  non-linearly  related  to  OM,.  To  obtain  a 
workable  approximation  to  the  relationship  between  OM,  and  OM/we  observe  that,  when  Aj 
operates  early  (OM,— OM;^  or  late  {OM^OMh,  OM/is  correctly  presented,  respectively,  by 
OM/  or  OM/.  In  fact,  we  will  require  our  approximation  to  satisfy  these  "boundary  condi¬ 
tions."  We  relate  OM]  to  OM,  by  comparing  OM,  with  its  bounds  OM,^and  OM/  and  then 
requiring  that  OM/must  operate  similarly  with  respect  to  its  own  bounds  OM/and  OM/ 

Let  us  define  p,U),  the  relative  progress  of  A,  at  time  t,  as 


0 

Z,U)-Zf-it) 

Z^(t)-Zl^U) 

1 


f-S, 


f-F, 


P,U)  = 


(3.10) 
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We  assume  Zf{t)-Zfit)>0  for  r-5,+l,...,/'y-l.  (Note  that  Zfid-Zfit)  for  and 
t—Fj.)  Re-arranging  (3.10),  the  operating  mode  OM,  can  be  expressed  as 

Z,(/)  -  Ztit)  +  PiU)[ZfU)-Ztit)\  .  (3.11) 

We  say  that  Aj  operates  early  at  t  if  Pi(t)“l,  and  operates  late  at  t  if  p,(r)-0.  Note  that  the 
window  curve  constraints  of  Section  3.2.4  are  equivalent  to 

0  <  Piit)  <  1  t—Sj. . .  .  .Fj  . 

To  compute  OA//— (Z/fr)},  we  equate  its  relative  progress  [pjU)],  to  the  relative  progress 
of  Ai,  Ip/Ct)},.  It  is  not  appropriate  to  do  this  with  a  simple  time  lag;  rather,  we  will  equate 
relative  progress  at  corresponding  points  of  the  windows  of  A,  and  Aj. 

Let  the  window  (Si,F,]  be  partitioned  into  M  subintervals  as  follows: 

iSiFi]  -  (f9,f^]  u  •  •  •  u  {/;?"-», u  •  •  •  u  iFl^-\F^ , 

where  Ff=Si  and  F^Fj.  We  denote  the  m'*  subinterval  (Fl"~^,FI^  by  Iml,.  The  interior 
partitioning  points  F},  ,  F^~^  are  determined  by  requiring  that  they  divide  the  area  between 

the  window  curves  (i.e.,  the  slack  of  Ai)  into  vertical  slices  of  approximately  equal  size: 

I  ZfU)-Ztit)  =  £  ZfU)-Zt{t)  -  . 

/€[ml(  ^  t—Sf  ^ 

We  partition  the  window  of  activity  A j  and  the  area  between  its  window  curves  similarly, 
using  the  partitioning  points  Fj",  m— 0,...,Af.  We  relate  [pjit)],  to  [ptU)),  by  equating  the  rela¬ 
tive  progress  of  each  activity  at  the  partitioning  points: 

pJiFf)  -  PiiFI^  m-0 . M  .  (3.12) 

For  interior  subintervals  (ml j,  m-2,..,Af— 1,  the  value  pJit)  for  each  f€  [ml j  is  taken  to  be  an 
interpolation  of  the  values  at  the  endpoints  of  (mly.  Inside  the  exterior  subintervals  [lly  and 
[M]j  we  assume  constant  progress  p/(F/)  and  p/fF/^'*).  The  transformation  from  {/>/(r)),  to 
{p/Xr)},  is  thus  completely  determined  by  the  following  expression: 

p](t)  -  XfidPiiFr^)  +  a-\fU))p,{F;^  /€  [ml,;m-l . M ,  (3.13) 

0  m-1 

—  t 

where  Xfit)  -  ■  J  . 

^  FJ*  -  Fj"“‘ 

1 


m^Af 
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The  operating  mode  OMj  is  then  determined  by 

Z]U)  -  Zj-U)  +  p;(t)[Zf(t)-ZjHt)]  t^Sj . Fj  . 

Note  that  the  transformation  preserves  the  desired  correspondence  between  OMf  and  OMf, 
and  between  OMf-  and  OMj‘. 

Recall  constraints  (3.9)  which  state  that  OMj  is  consistent  with  OM,  if 

Zj(t)  K  ZJU)  t~Sj, _ Fj  . 

This  is  equivalent  to 

pj(t)  <  pjit)  t^Sj,  .  .  .  ,Fj  . 

Using  (3.12)  we  obtain  the  relative  progress  tranter  constraints  for  the  partitioning  points: 

Pj(Ff)  <  A-CJf)  .  (3.14) 

Including  interior  time  points,  and  using  (3.13),  the  constraints  are  given  by 

PjU)  <  kf(t)Pi(Fr^)  +  il-kf‘it))pi{F!^  . M  .  (3.15) 

For  this  simple  case  of  intermediate  product  transfer  from  A/  to  Ajy  OMj  is  consistent 
with  OMi  if  its  relative  progress  does  not  exceed  the  relative  progress  of  A,  (with  respect  to  the 
transformation  (3.13)  from  {p/(t)},  to  {p/(r)),).  Similar  statements  can  be  made  for  all  types 
of  intermediate  product  transfers,  as  we  demonstrate  below. 

3.4.4.  Relative  Progress  Transfer  Constraints 

Recall  from  Section  3.4.1  that,  in  the  general  model,  the  intermediate  product  transfer 
constraints  were  given  by 

I  anjIjU)  <  f  CwO,(f)  A-l . /-I . T  . 

y-i  /-I 

The  constraints  state  that  input  of  each  intermediate  product  by  time  t  may  not  exceed  out¬ 
put  by  t.  In  this  section  we  present  analogous  constraints  stating  that,  at  corresponding  time 
points,  the  average  relative  progress  of  all  users  of  IP,,  may  not  exceed  the  average  relative  pro¬ 
gress  of  the  producers  of  IP,,'. 


(b)  Underlying  Key-op  Subnetwork 
EXHIBIT  3.13 


MEASURING  POOLED  INTERMEDIATE  PRODUCT  OUTPUT 
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£  a,jPj(Ff)  <  £  c,,Pi(F!^  A-1 . H\  m-0,...,M  .  (3.16) 

j~i  /-I 

These  constraints  are  discussed  below  fur  the  three  types  of  intermediate  products  introduced  in 
Section  3.4.1,  with  appropriately  chosen  coefficients  and  c^,. 

(1)  Single  Producer  and  User 

Suppose  an  activity  At  has  more  than  one  successor,  and  produces  a  distinct  product  for 
each  of  them.  We  assume  that  the  production  of  each  is  identically  distributed  in  relation  to 
OMt  and  therefore  apply  constraints  (3.14)  to  each  intermediate  product  output  IP,,  of  A,.  Let¬ 
ting  c*/— 1  and  5/,y— 1,  the  following  holds  for  /P*: 

a„jPj(Ff)  <  c,,tPiiFI^  ^  PjiFf)  <  PtiF!^  m-0 . M  .  (3.17) 

For  time  periods  within  the  partitiioning  intervals  we  interpolate  relative  progress  as  in  (3.15). 

Constraints  (3.17)  imply  that,  if  an  activity  has  multiple  predecessors  and  receives  distinct 
intermediate  products  from  them,  its  operation  is  constrained  by  the  relative  progress  of  each  of 
them. 

(2)  Single  User,  Pooled  Production 

Suppose  an  activity  Aj  uses  an  intermediate  product  IP,,  that  is  produced  by  several  activi¬ 
ties.  In  other  words,  predecessors  of  Aj  pool  their  output  for  use  by  Aj.  We  state  that  use  of 
IP,,  is  consistent  with  its  production  if  the  relative  progress  of  .4^  does  not  exceed  the  "average” 
relative  progress  of  the  producers  of  IP^.  At  the  partitioning  points  these  constraints  are  stated 
as  follows: 


Pj(Ff)  <  £  c„,p,{F!^  m-0 . A/,  (3.18) 

/-I 

where  the  output  coefficients  must  still  be  specified.  For  time  periods  within  the  intervals 
[ml  j,  we  interpolate  relative  progress  as  before.  The  details  are  omitted  here. 

We  motivate  the  use  of  constraints  (3.18)  by  giving  a  simple  example  shown  in  Exhibit 
3.13(a).  The  activities  A^  and  A,  pool  their  output  for  use  by  Aj.  Recall  that  a  key-op  subnet¬ 
work  similar  to  that  in  Exhibit  3.13(b)  underlies  Exhibit  3.13(a).  All  successors  of  key-ops 
within  Ar  and  A,  were  grouped  into  A j. 

Suppose  two  aggregate  activities  Ay  and  A,  had  ueen  formed  instead,  as  indicated  by  the 
dashed  lines  in  Exhibit  3.13(b).  Then  Ay  succeeds  A,  and  Ay  succeeds  A,.  Note  that  Ay  and 
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Ay  are  assumed  to  have  similar  work  content,  and  that  the  following  holds: 

ajZjit)  —  OuZuit)  +  OyZyit)  t-Sj,  .  .  .  ,Fj  .  (3.19) 

The  coefficients  Oj,  Ou,  and  Oy  are  the  total  resource  requirements  of  each  activity,  and 

Oj—Ou+ay. 

Let  us  consider  the  transfers  of  IP/,  in  terms  of  the  relative  progress  transfers  from  to 
A„y  and  from  A,  to  Ay.  Given  OM,  and  OM„  the  operating  modes  GAfJand  OMy  ior  which 
Au  operates  tightly  with  A^,  and  Ay  with  are  determined  as  in  (3.12): 

p'M  - 

pUF.)  -  p,(Ffl  •  (3.20) 

Our  goal  is  to  obtain  an  expression  for  OMjy  the  operating  mode  of  Aj  when  it  operates 
tightly  with  its  predecessors  Ay  and  A,.  From  (3.19)  we  know  that 

ZKt)  -  z;(/)  +  z;(/)  t~Sj . Fj. 

^  Q.  A‘  ^ 

J  J 

It  can  be  shown  that,  if  the  window  curves  of  A^  and  Ay  have  the  same  shape  (which  implies 
that  the  window  curves  of  ^4;  also  have  this  shape),  then  the  following  also  holds: 

PjU)  —  —  /»J(/)  +  ~  pIU)  t—Sjy...,Fj  .  (3.21) 

In  practice  this  condition  will  usually  only  be  approximately  satisfied. 

By  combining  (3.20)  and  (3.21)  we  obtain  relative  progress  transfer  constraints  on  the 
operation  of  Ay. 


p,(.Ff)  <  ^  p.<.Fri  +  ^  p,iJ?)  . 

Qj  Oj 

Comparing  these  constraints  with  (3.18)  we  see  that,  in  general,  the  output  coefficient 
should  be  the  proportion  of  resources  used  by  ^4^  to  perform  those  key-ops  which  succeed  key- 
ops  within  its  predecessor  A,. 
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(3)  Single  Produce,  Shared  Use 

If  intermediate  product  output  IPf,  of  activity  A)  is  shared  by  several  successors  of  A/,  the 
constraints  are  as  follows: 


y-i 

The  coefficient  is  taken  to  be  the  proportion  of  resources  used  by  A/  to  perform  those  key* 
ops  which  precede  key-ops  within  successor  Aj.  The  motivation  for  the  above  constraints  is 
similar  to  that  of  case  (2).  Note,  however,  that  tight  operation  of  one  successor  Aj  with  Aj 
implies  assumptions  on  the  operation  of  all  successors  of  that  share  IP/,.  It  is  therefore 
easier  in  this  case  to  interpret  tight  operation  of  the  successors  with  A,  in  the  opposite  direction. 
For  given  operating  modes  of  the  successors  we  would  seek  the  "latest"  possible  operating  mode 
of  A,.  The  interpolation  of  relative  progress  transfer  within  the  partitioning  intervals  is  best 
represented  backwards,  also. 


3.5.  Attainable  Window  Curves:  Workspace  Limitations 


3.5.1.  Workspace  Limitations 

In  Sections  3.2.3  and  3.2.4  we  developed  the  following  bounds  on  the  operating  mode  of 
each  activity  A,: 


0  <  z,(t)  <  z,(t) 

Z/- <  Z,(/)  <  2f(/)  . ■ 


(3.22) 


The  bounds  Z/(r),  Z/^r),  and  Z^t)  were  computed  by  summing  the  operating  intensities  of  all 
key-ops  within  A,  that  could  operate  at  time  t.  Although  each  of  these  key-ops  can  operate  at 
t,  they  cannot  necessarily  operate  together  at  t.  Workspace  limitations  (interferences)  may 
exist  that  restrict  the  operation  of  the  activity.  As  an  example,  there  may  be  insufficient  space 
for  the  concurrent  removal  of  all  engine  room  components. 

The  workspace  that  an  activity  A,  needs  can  be  considered  a  resource  that  is  unique  to  the 
activity.  We  express  the  limitation  on  the  availability  of  this  resource  as  an  upper  bound,  z,,  on 
the  operating  intensity  of  Aj. 


Zjit)  <  %  t^S„...yFi  . 


(3.23) 


Other  types  of  resources  that  are  unique  to  an  activity  can  be  treated  similarly. 

The  early  and  late  operating  modes  of  activity  Ai  do  not  necessarily  satisfy  (3.23).  For 
example,  suppose  At  is  preceded  by  a  restraining  key  event.  When  At  operates  early,  all  key- 
ops  within  At  start  operating  immediately  after  the  key  event  and  their  combined  intensities 
could  exceed  zt. 

Let  i4y  be  a  successor  of  A,.  If  the  early  operating  mode  of  At  does  not  satisfy  (3.23) 
then  At  cannot  transfer  intermediate  product  output  to  as  fast  as  was  originally  assumed. 
Therefore  the  early  operating  mode  of  is  infeasible,  and  the  workspace  limitations  on  A, 
should  be  propagated  onto  the  early  operating  mode  of  Aj'm  some  way.  The  limitations  on  At 
must  also  be  propagated  (indirectly)  to  successors  of  A j,  and  to  their  successors,  etc. 

In  general,  workspace  limitations  must  be  propagated  throughout  the  activity  network.  If 
the  early  operating  mode  of  an  activity  violates  (3.23)  then  the  limitation  is  propagated  forward 
through  the  network;  if  the  late  mode  violates  (3.23)  then  it  is  propagated  backward.  Note  that 
the  forward  and  backward  propagations  are  independent  of  each  other.  The  early  and  late 
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operating  modes  that  result  from  this  propagation  of  workspace  limitations  throughout  the  net¬ 
work  are  referred  to  as  being  attainable. 

In  Section  3.7.2  we  will  see  that  it  is  important  to  replace  the  original  early  and  late  modes 
with  the  attainable  ones.  These  are  computed  in  the  next  section.  The  constraints  (3.22)  and 
(3.23)  will  then  always  be  satisfied  for  the  early  and  late  modes,  but  we  must  still  explicitly  res¬ 
trict  all  other  operating  modes  to  satisfy  them,  and  also  the  relative  progress  transfer  constraints 
of  Section  3.4.3. 

3.5.2.  Propagation  of  Workspace  Limitations 

For  each  activity  Ai,  let  OMf^iZfit)) ,  and  OMf^iZf'it)] ,  be  the  attainable  early  and 
late  operating  modes  of  Aj.  We  could  compute  them  by  performing  simulations  on  the  key-op 
network  subject  to  the  following  constraints  on  key-op  start  time  schedules  S; 

b, 

X  —  2,  r=5,, 

t€\(S,t) 

where  A(5,r)  is  the  index  set  of  key-ops  within  A/  that  can  operate  at  /,  given  S.  We  would 
need  to  develop  considerable  programming  logic  (resource  allocation  rules,  activity  priority 
rules)  to  perform  these  simulations.  As  an  alternative  approach,  we  will  approximate  the 
attainable  modes  by  working  within  the  aggregate  model. 

Let  Aj  be  a  successor  of  activity  Aj  and  assume,  for  simplicity  of  exposition,  that  Aj  has 
no  predecessors  other  than  /4,.  Given  OMf,  we  compute  OMfas  follows: 

(1)  Determine  OMjMZjit)] „  the  operating  mode  of  Aj  when  it  operates  tightly  with  OMf 
(as  in  Section  3.4.3). 

(2)  Modify  OMj  to  reflect  the  workspace  limitations  on  Aj.  This  is  done  by  computing  the 
attainable  cumulative  intensity  Zfit)  recursively  for  t~Sj+\,...,Fj: 

ZjHt)  -  min  [Zfit-D  +  Zj  ,  ZjU)]  ,  (3.24) 

where  Zf{Sj)=Q,  and  Zjii)  is  computed  as  in  Section  3.4.3. 

The  computation  is  illustrated  in  Exhibit  3.14.  The  curve  Z/(/)  is  followed  until,  for 
some  /,  its  slope  exceeds  Zj.  We  then  extend  the  new  curve  with  slope  Zj  until  the  curve  Z/(  t) 
is  reached  again.  Note  that,  if  OA// satisfies  the  workspace  limitations  on  Aj,  then 
and  hence  OA// tightly  follows  OMf.  Also,  if  Aj  has  no  predecessors,  OA//can  be  computed 
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PROPAGATION  OF  WORKSPACE  LIMITATIONS 


by  using  (3.24)  with  OAf/ replaced  by  OMf,  the  original  early  operating  mode  of  Aj. 

The  attainable  early  operating  modes  are  computed  by  starting  with  those  activities  with 
no  predecessors.  Then,  proceeding  forward  through  the  network,  we  apply  (3.24)  successively. 
If  an  activity  has  multiple  predecessors  then  (3.24)  must  be  modified  appropriately.  If  an 
activity  shares  its  intermediate  product  output  with  multiple  successors  we  preallocate  the  out¬ 
put  (as  represented  by  the  activity’s  relative  progress)  equally  to  the  successors.  These 
modifications  are  easily  made  by  considering  the  different  types  of  relative  progress  transfer 
constraints  discussed  in  Section  3.4.4. 

In  a  completely  analogous  maimer  we  can  propagate  workspace  limitations  backward 
through  the  network,  the  details  of  which  are  omitted.  We  will  assume  that  the  computations 
of  this  section  have  been  applied  to  the  original  window  curves  of  all  activities,  so  that  they  are 
attainable.  Relative  progress  is  measured  from  now  on  with  respect  to  these  attainable  curves. 
In  general,  the  relative  progress  transfers  that  result  when  using  the  original  versus  the  attain¬ 
able  curves  will  be  different.  There  are  conditions,  however,  under  which  the  transfers  are  the 
same. 

These  conditions  frequently  arise  is  practice.  Consider  a  series  of  three  activities 
representing  removal  (RMV),  repair  (RPR),  and  reinstallation  (RI)  of  a  technical  system.  Sup¬ 
pose  that  the  removal  activity  RMV  is  preceded  by  a  restraining  key  event,  and  RI  is  succeeded 
by  a  restraining  key  event.  Since  RMV  succeeds  a  key  event,  its  early  mode  is  quite  peaked  (as 
mentioned  before  in  Section  3.5.1)  and  may  violate  its  workspace  limitation.  The  early  modes 
of  RPR  and  RI  are  much  less  peaked  since  the  key-ops  within  them  start  in  a  staggered 
manner.  Hence  the  early  modes  of  RPR  and  RI  may  not  violate  their  limitations.  Analo¬ 
gously,  RI  is  the  only  activity  whose  late  mode  is  likely  to  violate  its  workspace  limitation. 

Under  these  conditions  the  set  of  consistent  operating  modes  will  be  approximately  the 
same  whether  relative  progress  is  measured  with  respect  to  the  original  or  the  attainable  window 
curves.  This  is  true  as  a  direct  consequence  of  the  way  in  which  workspace  limitations  are  pro¬ 
pagated.  The  qualifier  "approximately  equal"  applies  since  we  interpolate  relative  progress  for 
the  time  periods  between  window  partitioning  points  (see  Section  3.4.3). 


EXAMPLES  OF  ACTIVITY  OPERATING  MODES 
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3.6.  Modeling  Activity  Operation  •  Computational  Issues 

The  aggregate  overhaul  model  is  part  of  an  LP  formulation  of  shipyard  resource  allocation 
described  in  Chapter  4.  Before  presenting  the  final  version  of  the  model  in  Section  3.7,  We  first 
discuss  some  computational  issues  relating  to  the  realism  of  activity  operating  modes  and  the 
number  of  decision  variables  involved. 

Suppose  the  operating  intensities  Z/(t),  r— are  taken  as  the  decision  variables 
for  operation  of  each  activity  A/.  The  activi^  operation  constraints  developed  thus  far  (intensity 
bounds,  window  curve  constraints,  relative  progress  transfer  constraints)  do  not  prevent  an 
operating  mode  from  being  obtained  that  is  obviously  unrealistic.  As  an  example,  consider 
Exhibit  3.  IS  (a).  The  properties  of  basic  solutions  to  the  LP  model  may  even  induce  such 
unrealistic  operating  modes.  Furthermore,  the  resulting  number  of  variables  and  constraints  in 
the  LP,  while  not  impossible  to  accommodate,  is  nevertheless  quite  large. 

For  these  reasons,  we  will  characterize  the  operating  modes  in  the  next  section  by  fewer 
decision  variables  in  a  way  that  more  realistic  solutions  are  induced.  To  motivate  our  choice  of 
decision  variables  let  us  discuss  a  few  simple  types  of  activity  operating  modes: 

(1)  Constant  Intensity:  The  activity  is  assumed  to  operate  at  a  constant,  but  variable,  rate  over 
a  subinterval  of  (5/,P/],  as  illustrated  in  Exhibit  3.15(b).  The  decision  variables  would  be 
the  activity  start  time  and  the  intensity  level.  This  type  of  operating  mode  is  not  easily 
reconciled  with  the  activity  window  curves,  and  does  not  reflect  aggregate  product  transfer 
characteristics.  Furthermore,  it  cannot  be  represented  by  linear  constraints  and  continu¬ 
ous  variables. 

(2)  Constant  Relative  Progress:  In  this  case  a  relative  progress  variable  p,  applies  over  the 
whole  window  of  A,.  See  Exhibit  3.16  for  an  example  of  the  resulting  intensity  curve 
z,(t)  and  cumulative  curve  Z/(/).  Note  that  this  type  of  operating  mode  is  a  convex  com¬ 
bination  of  the  window  curves.  From  the  development  of  Section  3.4.3,  we  know  that  it 
will  allow  intermediate  product  transfers  to  be  modeled  effectively,  but  the  results 
obtained  may  be  undesirable.  For  example,  if  zf{t)’^zfit)—c  for  some  t  then  we  are 
forced  to  have  Zi(t)^c  for  all  operating  modes.  This  is  obviously  too  restrictive.  If  c— 0, 
then  all  operating  modes  will  have  an  interval  with  zero  intensity  in  the  middle  of  the 
window,  which  is  highly  unrealistic. 
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(3)  Trapezoidal  Shape:  In  practice,  an  aggregate  activity  does  not  use  resources  at  a  constant 
rate.  Rather,  there  is  a  start-up  phase  during  which  resource  use  slowly  increases,  then  a 
fairly  steady  phase  of  operation,  and  finally  a  phase  in  which  resource  use  decreases. 
Exhibit  3.1S(c)  illustrates  this  trapezoidal  type  of  operating  mode.  In  the  next  section,  we 
show  that  such  operating  modes  can  be  approximated  in  terms  of  linear  constraints  and 
real  variables,  while  still  retaining  the  characteristics  of  relative  progress  transfer. 

3.7.  Three  Phase  Model  of  Activity  Operation 

In  the  last  section  we  outlined  the  following  desirable  properties  of  a  computational  model 
of  activity  operation: 

-  satisfaction  of  the  activity  operation  constraints 

-  few  variables  and  constraints 

-  "reasonable"  operating  modes,  e.g.,  trapezoidal  shape. 

The  three  phase  model  presented  below  is  an  attempt  to  satisfy  these  properties  without  making 
too  many  compromises. 

3.7.1.  Phase  Variables 

Let  us  partition  the  window  (S„F/I  of  each  activity  Aj  into  three  phases,  which  we  call  the 
first,  middle,  and  last  phases.  The  partition  is  defined  by 

(SM  -  u  U  {F},F,]  . 

We  define  one  decision  variable  for  each  phase  of  activity  .4,.  The  operating  mode  is  then 
represented  in  terms  of  these  phase  variables.  In  the  middle  phase,  we  choose  to  hold  operating 
intensity  constant,  and  denote  the  variable  for  intensity  during  the  phase  by  Zil2].  Instead  of 
intensity,  it  is  the  relative  progress  which  we  hold  constant  over  each  of  the  other  phases.  Let 
p,[\]  and  p/[3]  be  the  variables  of  the  first  and  last  phases. 

The  operating  mode  {Z/(/)},  can  thus  be  represented  by: 

ztu)  +  p\mzfu)-ztu))  Si<  f;' 
z,U)  -  +  {t-F,')zil2]  f;'  <  t  <  Fj^  (3.25) 

z/-(t)  +  Pi[3](Z^(t)-Z,Ht))  F}  <  t<  F^ 


Exhibit  3.17  shows  the  resulting  type  of  cumulative  intensity  curve.  This  construction  induces 


an  intensity  curve  which  increases  at  first,  is  then  constant,  and  finally  decreases  again.  (While 
the  resulting  operating  mode  is  not  trapezoidal,  it  is  a  fairly  good  approximation.) 

To  ensure  that  the  curve  is  continuous,  we  must  place  a  boundary  condition  on  the  opera¬ 
tion  of  y4i  at  time  r— namely 

-  aI31  ,  (3.26) 

which  is  equivalent  to 

Z,(/;2)  -  Z,HFi^)  +  p,l3](Zf(Fi^)-Z,HF/))  .  (3.27) 


Noting  that  z,(r)— Z/(r)-Z,(r— 1),  we  can  use  (3.25)  and  (3.27)  to  obtain  the  following 
expression  for  z/(t): 


z,(t) 


Si  <  f  <  F/ 

2, [2]  F/  <  F^  . 

zf-it)  +  Pi[3]L^it)-zf-(t))  Fi 


(3.28) 


Recall  from  Section  3.6  that  if  relative  progress  is  constant  throughout  the  window  and,  for 
some  r,  z<^r)— 2/^r)— c,  then  2,(r)— c  for  all  operating  modes.  Equivalently,  if  the  slopes  of 
Z^t)  and  Zfit)  are  equal  then  Z/(r)  must  have  that  slope.  To  avoid  prespecifying  the  slope  it 
may  be  necessary  to  modify  the  criterion  for  partitioning  the  window  into  phases  (which  was 
presented  in  Section  3.4.3).  Instead  of  partitioning  the  area  between  the  window  curves  into 
equal  thirds,  the  middle  phase  should  be  widened  to  include  all  time  periods  in  which  the  slope 
of  the  window  curves  is  equal.  Exhibit  3.18  shows  two  stylized  examples  of  this. 

Up  to  now  we  have  implicitly  assumed  that  resource  use  by  the  aggregate  activities  is 
measured  in  terms  of  the  time  units  of  key-op  resource  use,  namely  days.  But  shipyard 
resource  allocations  must  be  made  for  larger  time  intervals.  Hereafter  we  assume  that  time 
intervals  are  periods  of  two  work  weeks  (ten  working  days).  The  computation  of  the  activity 
operating  modes  is  performed  on  this  wrider  grid.  Clearly,  some  information  is  thereby  lost,  but 
daily  resource  use  cannot,  and  should  not,  be  represented  in  an  aggregate  model.  Resource  use 
by  activity  A,  during  each  two  week  period  (r— l,r]  is  given  by 


where  2/(r)  is  computed  according  to  (3.28). 
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3.7.2.  Activity  Operation  Constraints 

In  this  section  we  discuss  the  precise  form  of  the  constraints  on  the  phase  variables  of 
each  activity. 

Intensity  Bounds 

For  all  t^Si,  .  .  .  ,F,,  the  operating  intensities  of  activity  as  given  by  (3.28),  must 
satisfy 


0  <  2,(t)  <  !,(/)  (3.29) 

ZiU)  ^2,.  (3.30) 

First,  let  us  consider  the  middle  phase.  The  upper  bound  z,(  t)  is  usually  so  ineffective  that  we 
can  ignore  it.  What  we  do  require  is  that 

0  <  z,l2l  <  z,.  .  (3.31) 

It  may  also  be  necessary  to  place  a  non>zero  lower  bound  on  z,l2]  in  order  to  reflect  labor  crew 
indivisibilities.  Note  that  the  maximum  amount  that  could  be  performed  during  the  middle 
phase  is  given  by  ZfiF^  —  ZfiF})  .  The  upper  bound  in  (3.31)  is  therefore  redundant  if  the 
following  condition  holds: 

Zf(Ff)  -  Zt{F})  <  %  . 

In  the  first  and  last  phases  we  observe  that  Zi(r),  as  given  in  (3.28),  satisfies  (3.29)  by 
definition  (see  Section  3.2.3),  and  satisfies  (3.30)  by  construction  (the  window  curves  are 
assumed  to  be  attainable). 

Window  Curve  Constraints 

The  cumulative  intensity  Z/(/)  of  activity  A,  must  satisfy 

ZtU)  <  Z,(t)  <  ZfU)  t^S, . Ft  .  (3.32) 

In  the  first  and  last  phases  these  constraints  become  simple  upper  and  lower  bounds  on  the 
phase  variables: 


0  <  Pi[m]  <  1 


m— 1,3  . 
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Relating  the  constant  intensity  in  the  middle  phase  to  the  window  curves  would  be  more 
difficult.  Note  that  the  cumulative  intensity  curve  for  the  early  operating  mode  is  usually  con¬ 
cave  in  the  middle  phase,  and  for  the  late  mode  it  is  usually  convex.  Assuming  that  this  is  the 
case,  an  operating  mode  will  satisfy  (3.32)  in  the  middle  phase  whenever 

-  the  operating  intensity  is  constant  throughout  the  middle  phase  and 

-  the  operating  mode  is  within  the  window  curves  in  the  first  and  last  phase. 

(The  dashed  line  in  Exhibit  3.17  illustrate  this  argument.)  Since  these  conditions  are  satisfied 
by  construction,  we  need  not  explicitly  require  (3.32)  to  hold  in  the  middle  phase.  As  a  conse¬ 
quence,  however,  the  possible  operating  modes  of  an  activity  are  restricted  in  the  three  phase 
model  so  that  the  early  and  late  modes  can  only  be  approximately  achieved. 

Relative  Progress  Transfer  Constraints 

The  constraints  (3.16),  when  applied  to  the  first  and  last  phases,  become 

iV  _  N 

X  a^jPjlm]  <  £  Cf,iPi[m]  A-l,...,// ;  m=l,3  . 

7-1  /-I 

We  ignore  the  progress  transfer  constraints  in  the  middle  phase.  We  believe  that  the  small  loss 
in  accuracy  is  not  worth  the  difficulty  of  enforcing  such  constraints  in  this  phase. 

Summary 

The  operation  of  each  activity  Aj  is  represented  by  three  phase  variables  /;,[!],  z,[2),  />,[3]. 
The  operating  mode  is  a  function  of  these  variables,  as  shown  in  (3.28).  The  constraints  on 
activity  operation  are  summarized  below; 


0  <  r,(2]  <  z, 

/-I . N 

0  <  Pi[m]  <  1 

m-1,3; 

/-I . N 

N  N 

£  a^jPilm]  <  X  Cf,iPi[m] 

7-1  /-! 

m-1,3; 

A-1 . H 

Note  that  the  boundary  condition  (3.26)  in  the  middle  phase  becomes 


[Z^(F^)-Z[^(F^)]Pi[\]  +  (/}2_/r.i)^j2]  -  [Zf{Fi^)-Z,HFi^)]p^3] 

-  Z,HF^)-ZtiF,')  . 


By  using  this  relationship  to  express  one  of  the  phase  variables  in  terms  of  the  others,  we  can 
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reduce  the  number  of  variables  in  the  problem.  However,  each  such  substitution  would 
increase  the  number  of  inequalities  that  cannot  be  represented  as  simple  upper  bounds  on  vari¬ 
ables. 

3.7.3.  Adaptation  of  Three  Phase  Model  to  Overhaul  Data 

The  three  phase  model  was  adapted  to  the  aggregate  network  constructed  from  overhaul 
data  (see  Section  3.3.4).  Two  modifications  were  made,  however.  Referring  to  Exhibit  3.9, 
they  are  described  below: 

(1)  Activities  Ai,  A  24,  and  ^439  operate  with  so  little  slack  and  within  such  narrow  windows  that 
only  one  variable  per  activity  was  defined.  (Relative  progress  was  held  constant  throughout 
each  activity’s  window.)  Furthermore,  A32  has  so  little  slack  that  its  operating  mode  was  held 
fixed. 

(2)  The  overlap  between  engine  room  repair  and  reinstallation  activities  (A  2s, A  2s, A  30, A 31)  and 
the  succeeding  test  activity  (A2^  was  so  short  that  relative  progress  was  transferred  from  the 
last  phase  of  the  predecessors  to  the  first  phase  of  A  29.  The  same  modification  applies  to  the 
boiler  room  activities. 

Using  (3.33),  the  middle  phase  intensity  variables  were  substituted  for  relative  progress 
phase  variables.  As  a  result,  110  activity  operation  constraints  in  73  variables,  plus  upper 
bounds,  were  obtained.  Workspace  limitations  were  imposed  in  some  cases,  and  propagated 
through  the  network  (as  described  in  Section  3.5). 
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4.  SHIPYARD  RESOURCE  ALLOCATION  MODEL 

In  Chapter  1  we  identified  the  need  to  improve  aggregate  planning  in  the  shipyard.  Labor 
productivity  can  be  increased  by  making  the  allocation  of  labor  resources  to  overhauls  more 
explicit  and  consistent.  We  present  a  linear  programming  (LP)  model  that  helps  achieve  this 
goal. 

In  Section  4.1  the  aggregate  planning  process  is  discussed  from  two  perspectives:  overhaul 
planning  and  labor  resource  planning.  The  LP  model  for  resource  allocation  is  described  in 
Section  4.2.  We  suggest  ways  of  updating  overhaul  data  in  the  aggregate  model  in  Section  4.3. 
Finally,  computational  examples  are  presented  in  Section  4.4. 

4.1.  Aggregate  Planning  Process 

Exhibit  4.1  shows  a  simple  view  of  aggregate  planning  in  the  shipyard.  Overhaul  and 
labor  shop  information  are  combined  in  order  to  allocate  shipyard  labor  resources.  Labor  use 
plans  for  each  overhaul  and  utilization  plans  for  each  shop  are  thereby  derived.  We  discuss  the 
planning  process  first  from  the  viewpoint  of  overhaul  planning. 

An  overhaul  execution  plan  is  not  made  once  and  for  all,  but  evolves  dynamically  through 
time.  It  is  made  more  specific  as  information  on  the  overhaul’s  work  content  becomes  avail¬ 
able.  At  a  detailed  level,  the  execution  of  the  overhaul  can  be  described  as  a  network  of  key- 
ops  and  a  schedule  for  their  performance.  However,  the  planning  process  must  be  able  to  deal 
with  changes  in  labor  allocations  due  to  the  competition  for  labor  by  ongoing  and  future 
overhauls. 

We  therefore  place  detailed  overhaul  planning  in  the  framework  shown  in  Exhibit  4.2. 
Detailed  information  is  aggregated  and  combined  with  that  of  all  other  overhauls.  An  aggregate 
execution  plan  is  derived  and  then  disaggregated.  The  aggregate  plan  consists  of  a  labor  use 
plan  for  each  shop  and  a  timetable  of  key  events.  This  framework  is  not  intended  to  show  the 
progression  of  planning  steps  through  time.  Rather,  it  shows  the  continuous  coordination  of 
planning  at  different  levels. 

To  describe  the  framework  it  is  useful  to  follow  the  development  of  the  execution  plan 
from  an  overhaul’s  conception  through  its  completion.  When  it  is  first  conceived,  rough  esti¬ 
mates  of  labor  use  are  made.  A  preliminary  aggregate  overhaul  model  is  developed  from  his¬ 
torical  information.  Tentative  key  event  timetables  are  then  considered;  in  particular,  trial 
dates  are  established  for  important  restraining  events  such  as  docking  and  undocking. 
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Alternative  labor  use  plans  can  be  studied  by  experimenting  with  different  timetables. 

At  the  same  time,  detailed  overhaul  planning  (as  described  in  Section  1.2)  takes  place.  By 
using  this  information,  the  aggregate  overhaul  model  can  be  updated  and  rehned.  Once  labor 
allocations  to  the  overhaul  are  established  in  aggregate  planning,  scheduling  can  begin.  When 
the  overhaul  is  started,  a  specific  schedule  is  required  for  the  short-term  only.  Clearly,  labor 
allocations  and  schedules  for  more  distant  time  periods  are  tentative.  The  scheduling  network 
for  later  stages  of  the  overhaul  need  not  be  fully  developed. 

During  the  execution  of  the  overhaul,  labor  use  is  monitored.  The  progress  of  the  aggre¬ 
gate  activities  can  be  measured  in  terms  of  labor  application  versus  estimated  total  require¬ 
ments.  Labor  use  for  the  near  future  is  likely  to  be  partially  preallocated  due  to  previous  work 
crew  assignments.  We  refer  to  these  preallocations  as  labor  commitments.  As  the  overhaul 
proceeds,  the  flexibility  of  allocating  labor  for  future  time  periods  will  decline  until  all  future 
labor  use  has  been  committed. 

Let  us  now  turn  to  the  other  aspect  of  aggregate  planning,  namely  resource  planning.  At 
regular  intervals  the  utilization  of  labor  in  the  shipyard  is  re-evaluated.  The  status  of  all 
overhauls  is  updated,  there  is  an  extension  of  the  horizon  up  to  which  labor  use  is  studied,  and 
current  and  future  labor  shop  capacities  are  revised. 

The  LP  model  described  in  the  next  section  finds  the  most  efficient  utilization  of  shop 
capacities  while  taking  into  account  the  timely  completion  of  all  overhauls.  Simply  put,  we  try 
to  "pack”  the  shipyard  with  work.  Exhibit  4.3  summarizes  the  inputs  and  outputs  of  the  model. 
(In  Section  4.3  we  discuss  the  updating  of  overhaul  status  in  more  detail.)  The  model  provides 
plans  for  short-term  allocations  of  labor  among  overhauls  and  forecasts  of  future  labor  require¬ 
ments.  These  short-term  allocations  become  labor  commitments  when  the  analysis  is  repeated 
in  subsequent  time  periods. 
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4.2.  LP  Model  of  Resource  Allocation 

The  problem  of  determining  the  most  efficient  allocation  of  resources  (labor  shop  capaci¬ 
ties)  to  overhauls  is  formulated  as  a  linear  program.  We  characterize  the  model  in  terms  of  its 
variables  and  constraints,  and  discuss  its  objective. 

Variables 

Let  us  denote  the  ongoing  and  future  overhauls  in  the  shipyard  by  OH\,...,OHj.  The 
phase  variables  of  each  activity  Af  within  an  overhaul  OHj  determine  the  operating  mode 
{2,(r)),  of  A{,  and  hence  the  load  histories  of  for  each  labor  resource  Rk-  The 

amount  of  applied  to  OHj  during  (r— l,rl  is  denoted  by  xiU),  so  that  \ 

4U)  -  X  XkiU)  -  £  OkiZiit)  . 

Aii  OHj  OHj 

Although  the  activity  phase  variables  are  the  actual  LP  model  variables,  it  is  convenient  to 
express  resource  use  in  terms  of  the  linear  functions  xi{i)  of  these  variables.  We  restrict  our 
attention  to  resource  use  within  time  periods  (t— 1,/I,  t— 1,...,  T,  and  denote  the  allocation  of 
Rk  to  OHj  during  (O, Tl  by  {x]((r)),.  The  overhauls  do  not  necessarily  operate  only  within 
(O,  r],  however.  If  an  overhaul  finishes  beyond  T  then  not  all  of  its  activities  will  be  included 
in  the  model.  If  an  overhaul  is  in  progress  at  time  zero,  some  phase  variables  will  be  pre¬ 
determined. 

Constraints 

Activity  Operation  Constraints:  These  constraints  (summarized  in  Section  3.7.2)  describe 
the  set  of  consistent  activity  operating  modes  in  terms  of  the  phase  variables.  Overhaul 
resource  allocations  {xj^(r)},  that  satisfy  these  constraints  are  said  to  be  feasible.  Note  that  the 
constraints  depend  on  the  specification  of  activity  window  curves,  which  are  computed  for  given 
key  event  timetables.  To  examine  the  impact  of  alternative  timetables,  repeated  LP  runs  are 
required,  as  already  mentioned. 

Resource  Capacity  Constraints:  A  resource  allocation  to  OHj  may  be  feasible  as  far  as  the 
execution  of  OHj  is  concerned,  but  we  must  take  into  account  the  competition  for  resources 
among  overhauls.  For  each  labor  resource  Rk,  the  total  amount  applied  in  the  shipyard  during 
time  period  t  is  constrained  by  the  shop  capacity  XkU),  which  is  assumed  known.  The  resource 
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capacity  constraints  for  each  time  period  r— 1,...,  T  are  then  given  by 

J 

£  xiU)  <  \U)  k~\,...,K  .  (4.1) 

7-1 


Objective 

A  set  of  resource  allocations  to  overhauls  is  to  be  selected  that  utilizes  the  capacities  (up 
to  the  time  horizon  T)  most  efficiently.  More  specifically,  we  seek  feasible  allocations  {xj((/)), 
for  all  OHj  and  which  satisfy  (4.1)  and  maximize 

T  K  J 

£  a,  £  £  xi(t)  , 

/—I  At— 1  J—l 

where  the  coefficients  ai,  .  .  .  ,  a  rare  still  to  be  determined.  Note  that  the  resource  application 
during  period  t  for  all  labor  types  is  weighted  by  a  „  since  we  assume  that  application  quantities 
for  different  labor  types  are  in  comparable  units  and  can  be  added  together. 

We  define  the  efficient  utilization  of  shipyard  resources  to  mean  that  the  sooner  work  is 
assigned  resources,  the  better.  Furthermore,  the  value  that  is  placed  on  shifting  a  unit  of 
resource  use  from  a  time  period  t  to  time  r-1  is  assumed  to  be  independent  of  t.  This  implies 
that  the  coefficients  a ,  are  linear  in  f  and  decrease  with  increasing  t.  They  are  set  accordingly: 

a,  “  T—t+\  . 

The  resulting  objective  function  is  given  by 

T  K  J 

max  £  (r-f+1)  ^  t,  xlit)  .  (4.2) 

f-l  k~l  J-\ 

The  objective  of  applying  resources  as  soon  as  possible  is  equivalent  to  operating  the 
overhaul  activities  as  "early"  as  possible,  as  we  will  now  show.  Let  A/  be  an  activity  within  an 
overhaul  OHj,  operating  according  to  OA/,-{Z, (/)},.  Recall  from  Section  3.2.4  that  the  slack 
of  A,  (the  area  between  its  window  curves)  is  given  by 

<»■/  -  £  -  ZtU)  . 

t^Si 


ik 
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We  define  the  earliness  of  A/,  denoted  by  /*,,  as  the  proportion  of  the  area  between  the 
window  curves  that  lies  below  Ziit): 

Pi  =  —  Z  ' 

O’/  f-S, 


If,  for  example,  At  operates  early  then  P/— 1;  if  At  operates  late  then  P,— 0.  Roughly  speaking. 
Pi  is  the  proportion  of  the  slack  of  Aj  that  is  not  "used  up"  when  A,  operates  according  to  OA/,. 
Note  that  the  earliness  of  At  can  also  be  interpreted  as  the  weighted  average  relative  progress  of 
Ai  during  its  operating  window.  That  is.  Equation  4.3  can  be  rewritten  as 


Pi 


> 


where  cr,(r)  =  Zf(t)-ZtU)  is  the  component  of  o-,  "accruing"  from  time  period  t. 

It  can  be  shown  that  the  resource  utilization  objective  (4.2)  is  equivalent  to  maximizing 
activity  earliness,  if  the  contribution  of  each  activity  is  weighted  appropriately.  Let  us  consider 
the  value  of  operating  an  activity  A,  early.  First,  the  larger  its  resource  use  (a,),  the  greater  the 
effect  of  early  operation  will  be.  Second,  the  larger  its  slack  (cr,),  the  greater  is  the  difference 
between  operating  early  or  late.  These  two  activity  parameters  are.  reasonable  choices  for 
weights  on  activity  earliness.  In  fact,  it  turns  out  that  the  resulting  objective,  shown  below,  is 
identical  to  (4.2),  up  to  a  constant  term: 

J 

max  Z  Z  Oi^i^i  • 

j~\  A,iOHj 

'This  form  of  the  resource  utilization  objective  emphasizes  the  contribution  of  each  aggregate 
activity. 

At  this  point,  our  approach  to  aggregate  planning  becomes  clear.  We  seek  operating 
modes  for  all  activities  which  are  feasible,  but  which  "pack"  the  shipyard  with  work  as  much  as 
possible.  In  a  sense,  productivity  is  being  maximized. 


4.3.  Updating  Overhaul  Data  for  LP  Model 

The  resource  allocation  model  described  in  the  last  section  requires  up-to-date  informa¬ 
tion  on  all  ongoing  and  future  overhauls.  If  a  key-op  network  exists  for  an  overhaul,  and  is 
kept  updated,  then  we  can  re-aggregate  from  it  to  reflect  the  current  overhaul  status.  In  prac¬ 
tice,  however,  this  may  not  be  achievable.  We  therefore  suggest  updating  methods  at  the 
aggregate  level. 

Labor  Commitments 

As  an  overhaul  is  executed,  the  status  of  each  aggregate  activity  changes.  In  Section  4. 1 
we  discussed  labor  commitments  during  an  activity's  operation.  If  the  activity  is  about  to  start 
(or  just  started),  its  operation  will  be  predetermined  (i.e.,  its  labor  committed)  for  a  portion  of 
its  window;  if  it  is  well  underway  then  its  operation  may  be  completely  predetermined.  It  is 
convenient  to  assume  that  the  operation  of  an  activity  may  be  predetermined  up  to  the  end  of 
either  its  first  or  last  phase. 

In  order  to  transfer  the  relative  progress  of  a  partially  predetermined  activity  to  its  succes¬ 
sors,  the  value  of  one  or  both  of  its  relative  progress  phase  variables  must  be  determined.  For 
a  given  commitment  of  labor  (converted  to  an  operating  mode),  we  approximate  the  value  of  a 
phase  variable  by  the  weighted  average  relative  progress  for  time  periods  within  the  phase. 
This  is  analogous  to  activity  earliness  (see  Section  4.2)  being  the  average  progress  throughout 
the  wAo/e  window. 

Work  Content  Revisions 

Now  suppose  that  the  work  content  is  revised.  If  the  revision  applies  uniformly  during  the 
activity’s  operation  then  its  intensity  can  simply  be  rescaled.  If  a  few,  but  significant,  key-ops 
within  the  activity  are  revised  then  only  a  portion  of  the  window  may  be  affected.  In  this  case 
the  window  curves  must  be  modified  in  shape  "locally”  within  the  window. 

Key  Event  Date  Revisions 

If  the  execution  of  an  overhaul  is  delayed  substantially,  key  event  dates  will  need  to  be 
revised.  Also,  for  future  overhauls  in  the  planning  stage,  alternative  key  event  dates  will  be 
experimented  with.  In  either  case,  these  shifts  in  dates  will  cause  the  operation  window  of 
some  activities  to  be  shifted  also. 
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We  consider  the  case  where  a  key  event  is  shifted  forward  by  one  time  period,  i.e.,  two 
weeks.  (The  shift  backwards  in  analogous.)  The  early  window  curves  of  activities  succeeding 
the  key  event  should  be  shifted  forward;  the  late  curves  of  activities  preceding  it,  backward. 
The  shifts  are  then  repeated  (propagated)  for  activities  that,  respectively,  succeed  or  precede 
these  "neighbors"  of  the  key  event,  etc. 

Suppose  an  activity  A  whose  early  curve  is  shifted  forward  is  one  of  several  predecessors 
(not  all  of  which  are  affected  by  the  shift)  of  another  activity  B.  If  the  slack  of  B  is  consider¬ 
ably  less  than  that  of  A  then  the  early  curve  of  B  is  probably  influenced  more  by  predecessors 
other  than  A.  In  this  case  some  other  type  of  propagation  of  the  shift  in  the  key  event  date 
will  be  more  appropriate,  e.g.,  a  stretching  of  the  early  curve  of  B. 

4.4.  Computational  Examples 

The  LP  model  was  applied  to  allocating  resources  to  the  overhaul  described  in  Chapter  3; 
the  most  efficient  overhaul  labor  use  plan  was  computed  for  given  labor  shop  capacities.  The 
activity  operation  constraints  consisted  of  110  inequalities  in  73  variables,  plus  upper  bounds  on 
the  variables.  (See  Section  3.7.3.)  For  20  time  periods  and  12  labor  shops,  240  capacity  con¬ 
straints  were  added. 

The  obtained  allocations  are  summarized  by  comparing  total  resource  use  with  that 
derived  from  early  and  late  overhaul  execution  without  capacity  constraints.  Let  X(.t)  be  the 
total  amount  of  resource  use  up  to  time  t  in  the  optimal  solution,  so  that 

Xit)  “  Z  Z  • 

T-l/t-l 

Let  X^it)  and  A'^(r)  be  the  cumulative  resource  use  for  early  and  late  unconstrained  overhaul 
execution.  Clearly, 

^  XU)  4  X^it)  t~l,...,T. 

If  resource  use  were  not  constrained,  the  optimal  solution  would  of  course  be  early  execu¬ 
tion.  However,  labor  shop  capacities  were  set  at  about  60%  of  the  peak  loads  arising  from  early 
overhaul  execution,  so  that  labor  use  must  be  leveled  considerably. 

Exhibit  4.4  shows  the  cumulative  resource  use  curves.  Note  that  the  objective  function 


(4.2)  can  be  rewritten  as 


OPERATING  INTENSITY  CunULATIVE  INTENSITY 


1 . 0 
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so  that  it  can  be  interpreted  as  maximizing  the  area  under  the  curve  Xit).  Let 
Ar(f)  —  ^Xic(t)  be  the  cumulative  available  capacity,  also  shown  in  Exhibit  4.4.  The  slope 

T-l  *-1 

of  X^it)  and  X^[t)  exceed  the  slope  of  X(t)  at  some  time  points,  illustrating  that  they  would 
violate  the  capacity  constraints.  Also,  while  X(i)  does  not  seem  to  reach  the  slope  of  X(.t) 
anywhere,  this  is  due  to  the  fact  that  labor  application  from  each  shop  is  constrained,  not  only 
total  labor  use. 

The  capacities,  as  they  were  set,  still  allowed  considerable  flexibility  in  overhaul  execu¬ 
tion.  All  cumulative  resource  curves  X(t)  will  lie  within  the  area  between  the  extremes  X^(t) 
and  X^(t).  In  the  optimal  solution  the  curve  lies  above  63%  of  that  area.  As  an  experiment, 
the  objective  function  was  minimized  (the  later  that  work  is  assigned  resources,  the  better). 
The  resulting  cumulative  resource  curve  was  above  only  35%  of  the  area  between  the  extremes. 
The  flexibility  of  executing  the  overhaul  is  thus  equivalent  to  63-35%  =  28%  of  the  area. 

Exhibit  4.5  shows  an  example  of  a  three  phase  activity  operating  mode  obtained  from  the 
LP,  together  with  its  early  and  late  operation  extremes.  (This  is  activity  .427;  see  Exhibit  3.9.) 
Note  that  constant  relative  progress  within  a  phase  does  not  imply  monotone  behavior  of 
operating  intensity,  as  shown  in  the  last  phase. 

Let  us  consider  a  more  realistic  problem  size.  We  assume  a  constraint  set  per  overhaul  of 
150  inequalities  in  100  variables.  While  some  of  the  overhauls  will  be  partially  completed,  sup¬ 
pose  the  equivalent  of  15  whole  overhauls  are  to  be  analyzed.  Setting  a  time  horizon  of  two 
years  (50  time  periods)  with  12  labor  shops,  the  total  problem  size  is 
(150) (15) +  (50) (12)— 2850  inequalities  in  (100) (15)  — 1500  variables,  which  is  readily  handled 
by  LP  computer  packages.  We  see  that,  computationally,  the  resource  allocation  model  is  feasi¬ 
ble. 
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Kiaiiuii.  lEiuaiivc  ^cy  cveni  umeiaoies  are  men  consiaered;  in  particular,  trial 
dates  are  established  for  important  restraining  events  such  as  docking  and  undocking. 
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